How have the DVCSs worked for you so far?
dukeofgaming
I'm following both bitbucket and github repositories for the Joomla
Platform and I recently saw you updated the bitbucket repo, so I'm
assuming you've had a more or less equal share of experience with both
tools, and I'd really love to know how has the DVCS experience been
for each one of you.
Before it is assumed, I don't want to raise any git vs mercurial
debate, or try to find out if there is a final decision with regards
of an official choice of a DVCS for Joomla. It is just that I find
this case of experimental DVCS adoption very exemplar and healthy for
any open-source project (and code project in general for that matter),
and I'd love to read your opinions regarding the switch.
Best regards,
David
Andrew Eddie
Some people might still be using forks on the bitbucket repo but
master hasn't been updated for 3 weeks (when we swapped to github). I
don't know if there are any plans to keep bb in sync or not - if
anyone is interested in doing that they can talk to the PLT about it I
guess.
Anyway, to answer your question, I'm totally in love with DVCS on a
number of levels.
The first level is for my work purposes. I deal with a client on-site
and their firewall prevents me from accessing and sort of repo
remotely. Subversion was a pain because I'd have to save up a days
worth of changes, then remember to commit that at night. I'm the kind
of guy that likes to make one change per commit so this was a lot of
work to remember the incremental changes at the end of the day.
Swapping to hg initially was a Godsend. At least I could commit to
the local repo as frequently, or not, as I liked and just push that
night (but then it wasn't a big deal if I didn't get to push). That
alone was a big business life changer for me, significant enough for
me to wish I'd swapped over years ago.
Getting into hg from a project level though made me realise how
subversion holds us back from contribution. It makes you realise how
horrible branches in SVN are when dealing with large numbers of
contributors and large numbers of branches.
The attitude that "everything is a fork" also breaks down these
barriers of what's a fork and what isn't. Well, everything's now a
fork and if it finds its way back to master, well and good, but if it
doesn't but is useful elsewhere, hey that's awesome too.
While I actually find hg easier to use, and the plans on bitbucket are
probably a bit better from a storage point of view, the decision to go
with git came down to 1) the granularity by which pull requests could
be made (bitbucket just didn't cut it), and 2) it's perceived to be
*the* place to host the *serious* projects. The collaboration
features alone of github win hands down (and the eGit on Eclipse takes
care of a lot of the hard work you'd otherwise do on the command
line), but we felt that most of the high flyer developers that we'd
like to attract to working on the platform, and ultimately anything
that's built on it, would be working in git.
All up, loving it and hoping to see many more people using it and
forking Joomla in the future :) I think it's one of the best moves
we've made in a long time, very much complimenting the changes we've
made in the release cycle and other areas of the project.
One of the things we obviously need now are some good docs to get
people started in using git, how, for example, the JBS get into it and
then suggestions for how to manage features you are building. Since
I'm a noob myself still, that's not something I feel competent doing
just yet :)
Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla 1.6 developers
> --
> You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
> To post to this group, send an email to joomla-dev...@googlegroups.com.
> To unsubscribe from this group, send email to joomla-dev-frame...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/joomla-dev-framework?hl=en-GB.
>
>
elin
rickblalock
contrib to the docs.
What most people do is create branches (remote and local) from their
fork and merge forked branches before issuing a pull request to the
origin.
Paladin
putting them here partly as instruction and partly to hear better
ideas from anyone else):
They both begin by creating an account on github for yourself, then
forking joomla-platform into it. Git has great instructions for this,
and for setting up access.
Then you clone your fork on your local system. Do this using the ssh
option (note the three buttons near the top of your github repo: SSH |
HTTP | Git Read-Only
You click the SSH button and copy the URL in the box for your local
git clone command.
Then create a second remote branch for the original joomla/joomla-
platform repo. Do this by clicking the Git Read-Only button on the
Joomla repo page, copying that URL, and using it in your git remote
add command (git remote add git://github.com/joomla/joomla-platform.git).
It's at this command the two possibles diverge.
One way is to create a local tracking branch at the same time (git
remote add -t branchname git://github.com/joomla/joomla-platform.git).
The other just uses the command I listed previously.
The differences between the two comes in how you merge changes into
your repo from the main. One way pulls the remote changes right into
the main branch of your local repo, the other merges them into a local
copy of the joomla repo first, then lets you handle the merge locally.
I don't know if there's an objectively appreciable difference in
either way, but the second (creating the local tracking branch)
"feels" safer to me.
The first way, you would simply fetch the changes into your branch:
git fetch remotebranchname and the changes are brought down from the
remote and merged into your current branch.
The second way you would checkout the tracking branch, git pull to get
the changes merged into it, then checkout the master branch and git
rebase trackingbranch from there to move your changes past the head of
the joomla repo.
Yes I just hit the high points and didn't write it as a step-by-step
recipe. That's because I want to hear if anyone has a better way.
Writing this up clearly would encourage people to follow it, and I'd
rather they follow the best way, which may not be my way. If no one's
got a better way, I can then write this up in a more accessible way.
BTW, I generally do a lot of small commits, then do a git rebase -i to
collect the small commits into larger, logical ones, before pushing.
The drawback to this method is you then need the discipline (or anal-
rentitiveness) to go back via git resets to test the larger commits to
make sure they work independently.
One of the real attractive features of git is that nothing you do in
it is permanent, except saving code. But like every useful tool, it
can hurt you as well, if you're not careful with it.
dukeofgaming
@Andrew
Really nice to see the switch paid-off. Would you use SVN again for
any other project or specific task?, if so, which one and why?.
Also, how did you feel git's learning curve after hg?, do you think it
would have been better to jump right into git from the start?.
@Paladin
In your opinion, why are larger and commits better than smaller ones?.
Personally, I think preserving the history intact can serve better a
project than being able to refactor it (i.e. errors become
documented), unless maybe we are speaking of a release branch.
@all
Do you think, after using both tools, git has a higher barrier of
entry than hg?.
Are you planning/thinking on creating a hierarchy of integrators by
persons and/or teams and/or roles?, or just considering different
branches (e.g. bugs, features, experiments-XYZ)?. In other words, do
you think using the DVCS to the fullest would bring any benefit?:
http://docs.joomla.org/images/b/bf/DistributedVCS_Complex.png
How much would you say that github influences your decision of
sticking with git?.
Are you considering having Joomla just on the repository service?, or
do you plan to host an official repo on a Joomla server.
Finally, would you consider —as a project— that it would be a good
thing to use both tools (as long as there was someone syncing the
repos)?, or that one tool suffices and the there is no actual value in
this and only one tool should be used?. Why?.
Sorry if the questions feel like an interview =P, but I'm really
interested in very specific feedback in relation with lots of
arguments I've seen on the web.
elin
Paladin
ability to back slowly out of whatever blind alley you just chased
down during your development. But where that breaks down is after the
development is done, when you're about to push up to the public repo
and issue a pull request. (Note this applies not so much to single-
line bug fixes, but to longer, more complex, changes.)
During the work on a single complex change, I might have committed
multiple small steps along the way, maybe even committed a few
missteps as well that I had to revert, or just re-edited to correct.
If I push that up to my public repo, I now have to issue a pull
request covering many commits. Likewise, if there proves to be a
subtle error in my work that requires backing the changes back out of
the tree, multiple commits have to be undone.
OTOH, if I collect all the commits for that particular change into
one, then only one change needs to be pulled into the main tree, and
only one change needs to be undone to back it out. I've lowered the
complexity of the administration task, and what has been lost?
Does it truly serve anyone's purpose to know that I worked for a while
this afternoon on a particular file, then picked it up again tomorrow
morning, and then finished the work on the change wednesday at
midnight? Who would really profit from that record of commits? Or, for
that matter, that I decided to change the name of an attribute on a
new class I was writing after a few days of reflection? Who really
needs that information, or for that matter, who even cares about it?
As for keeping a record of every false start and blind alley -- does
anyone spend time in the source tree looking at that? Seriously?
Once it hits the public repos I'm more sympathetic to that point of
view (preserving the record of commits) but keeping track of every
little twist and turn, or stop and start, that happened in my local
dev tree just clutters up the public tree -- it adds volume, but not
value.
(I think part of this may be a disconnect caused by "svn thinking."
With svn, everything was permanent, which made one pause and think
before committing. Because of permanence the commits were Important,
and were not undertaken lightly. Which had the unintended consequence
of causing one not to use it so much as an aid in development, but
rather as a means of publication -- code got committed because someone
else needed to see it, not because of svn's code management features.
OTOH, I'm likely to commit changes simply because I'm done for the
day, not because the work is complete in any sense of the word.)
The major drawback of this approach is not loss of historical record
but that the developer who does this will not go back and test each of
the "condensed" -- or squashed -- commits individually, to ensure no
mistakes were make in collating them, that you actually *can* back
them out individually without breaking things. (This risk is lowered
when all changes are squashed into 1, not always possible.) But then,
all power tools have safety procedures their users should follow or
risk damaging themselves or their surroundings.
rickblalock
wonderful GUI for Git. You can easily drag and drop branches to force
a merge - has a nice way to approving specific lines of code to a
commit instead of just the bulk change, etc. It has some command line
tools too like 'gittower --init' will git init a directory and also
create the Gittower reference; gittower --status will open up your
repo in gittower to look through things, etc. I don't use it for the
simple stuff but when you have to merge someone else's stuff, cherry
pick things, etc. it's super nice. Check it out.
http://www.git-tower.com/
Andrew Eddie
>
> @Andrew
>
> Really nice to see the switch paid-off. Would you use SVN again for
> any other project or specific task?, if so, which one and why?.
I'd recommend DVCS to a client now if they weren't using anything
else. I'd only use SVN if I was forced to for
historical/infrastructure reasons.
> Also, how did you feel git's learning curve after hg?, do you think it
> would have been better to jump right into git from the start?.
Um, I'm glad I did it in the order of hg, then git. hg makes a lot
more sense coming from svn, and learning the most simple ropes in hg
helped a bit with git. I'm a bit better on the command line with hg
compared to git. git seems to be a bit more complicated there so I'm
really flying by the ability for eGit to hold my hand a lot.