If you imagine a pole one yard high, then CVS is about an inch up, SVN is a hair's width above that. Then git is an inch down, and hg is a hair's width below that. Or vice versa. The point is: If you pick either hg or git, you've already won.
Nevertheless you do need to pick, so, in the secure knowledge that if you pick the wrong one, you've still made a pretty good choice: There's virtually nothing that one of the two CAN do that the other CANNOT. This may involve plugins but this isn't all that harmful, in my opinion, primarily because external parties don't need to know about the plugins used by the main committers, if that's an issue (i.e. for open source projects or sufficiently large companies). But, there's a different general outlook on how version control should be done by the two camps. While you can work 'the hg way' on git and vice versa, this is not a good idea as you'll have a much harder time asking questions and making it all work just the way you want it to. Thus, this is an important issue for you: (A) Do you feel that changesets should be akin to deliverables, i.e. make sense as a whole and be engineered a little to be eminently reviewable, and in addition to that, the entire history is relatively easy to traverse, i.e. not too many irrelevant merges and branches, OR: (B) Do you feel that an accurate history is important? Both tools can do either, but in my experience, git users like A, and hg users are more in the B camp. To make this a bit more practical: In git, I (and many others) work like this: We update master, we then *create a new local branch*, even if I expect I'll be working for all of 5 minutes on something, I then do my work in this branch, committing complete crap, debug statements, code that doesn't even compile, etc, in that branch. That way I can switch right back to master if I need to. Once I'm done with my feature, I "git rebase -i master" (i.e. actively rewrite history since I branched), and clean up my various commits into a few sensible wholes. (I reorder where needed and squash things together, then update the commit messages to make sense). As a side-effect of squashing, unfinished code and debug statements disappear. I then switch back to master, update it, then I again rebase my branch, this time replaying the branch on top of the new master. If this is possible (if there were serious conflicts it won't be, and then you merge, but usually this is conflict free), then I merge my local branch into master, delete the branch, and push my changes. The upshot of all this is that my branch name does not pollute namespaces (I can reuse it later, no problem), and looking back in history across my repository, it's mostly a straight line with each commit having a low "WTF is going on here" ratio. Even though in actual practice development is highly branchy. You could go the git way and even merge branches that could be fast-forwarded with force-merge just so you have a historic record of the fact that a bunch of commits were in fact developed on a branch, and I can save the branch names. This is more what hg does (especially saving branch names for posterity). I personally like having short-lived branch names for features that are at some point just 'done' and become part of the main entity, because it means I can develop all features, no matter how trivial, as branches, which just works better. But that's me. Note that you can make hg work just like that with some effort and a few plugins, as I said at the beginning. Other than the above consideration, these are the other 3: (A) hg works a lot better on windows*, (B) git is simpler to grok. Once you grok git, actions like wiping a file from history because, let's say, you accidentally overwrote the copyright headers and now you're being sued (oh, how contemporary of me!) is easy. (C) git appears to have about 10x the userbase, at least, compared to hg. hg in turn is much 'bigger' than bzr, though this is harder to put in numbers (as KDE or gnome or whatsit uses bzr, in absolute developers there's rather a lot, but its limited to a few projects which IMO is clearly worth a lot less than loads of smaller projects using it). As a defense for git, I do not believe that developing without a posix shell is a sensible thing in the first place. Even without git I'd put msys/cygwin on a windows machine (if I was forced to work on that OS in the first place), make sure its reasonable well kitted out, and do my development there. Once you have all this, git works just great on windows, and, in fact, going with the msys-with-git install is one way to make this happen. NB: Piece of advice, do NOT try to use hg or git plugins for your IDE, at least not right now (not good enough) and not at first (because you should learn a little bit about how git/hg work before you do that, even if the plugins were good). Get used to 'git gui' and friends. If you're on macs, download the brotherbard fork of 'gitx' (googlable terms), it's like git gui but better. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
