|
Here's my experience with each. I'm biased and stubborn here, but in ways that may or may not be relevant to you. Your circumstances will differ, so take any advice about this with a grain of salt. I've used distributed VC systems for quite a while, at least in the small. I find VC systems, databases, and the like verrrry interesting (due to a past life working in libraries), and an acquaintance of mine was the primary author of Monotone. I had already been keeping my home directory and /etc in svn, but that sounded far more interesting (it was also a full backup!). I tried it, and found using repository-as-a-whole versions more convenient than per-file versions. Later, I tried out hg, and felt it had a nicer interface / was easier to set up for common operations. (mtn assumed you cared to set up strong crypto auth for everything.) I was quite happy with Mercurial - it's a good system. After using hg for a while (nine months or so?) I tried out git. It was still rough around the edges (the interface and documentation have since gotten better), but it had one major feature that stuck out - its ability to nonchalantly create and shuffle between several local, topical working branches in the same repository. To my knowledge, Mercurial still doesn't have a comparable feature, since their decisions about the core data structures make it awkward -- git saves the repo in terms of data snapshots, while hg saves the diffs (or perhaps vice versa, I forget). There was a major release where the hg team introduced "bookmarks", which were an attempts to emulate the git branching model, but you still had to be careful about copying them from one repo to another, etc. It had different trade-offs. I stopped paying attention around then. (If hg has since gained these, it would be a major point in its favor.) That sounds overly negative towards hg, though. A major con of git is that the system is heavily skewed towards running on Unix. If you install it on Windows, it uses vim as the default editor for comments, it assumes you're used to man pages, etc. As a whole, the native behavior of the platform is an afterthought. Lots of little Unix-isms. Now, I can't blame them - I use OpenBSD at home, and strongly prefer old-school Unix in general. Also, developing any kind of system with the niceties that Unix provides and then porting it to Windows later is a big pain. Still, Mercurial's releases have consistently seemed to more evenly support Windows. I develop for Windows at work (in a field involving high-performance graphics and associated hardware), and, for my own circumstances, would choose Mercurial over git. Again, I should stress they're both a landslide better than any other systems I've seen. Also, mercurial seems to place more emphasis on being simple for basic use, yet having a clean foundation for adding extensions. I haven't written any, or looked at it in a while, but it seemed like a good example of the different design styles - git was more powerful but scruffy, while mercurial was clean and more concerned with usability. (Whether this is an emergent property of git being written in C and shell scripts vs mercurial in Python with hotspots in C would be an interesting debate.) I still use git for my home directory and personal projects, though most systems' flaws aren't a big deal for smaller projects. Feel free to experiment. If you're doing research prior to committing to one or the other for a massive project, switching really isn't a big deal until you have branches with months of churn. Unless you're working on the Linux kernel or an equally massive project (unlikely), it'd be far easier (in isolation - not counting retraining) to just pick one, use it for a couple months, articulate pros and cons, then switch and compare. They have quite a bit in common, and either would be vastly preferable to svn (ack!) or perforce (ACK!!!). You can't make an informed decision without trying either, and they're both quite good. I looked into Darcs as another system that had interesting features and a pretty nice interface, but given the problems with bootstrapping an even remotely recent version of GHC on BSD (http://hackage.haskell.org/trac/ghc/ticket/1346), there's no way in hell I'd depend on Haskell for something as fundamental as VC. Also, weird web2.0 juice nonwithstanding, it's a version control system, not a religion. It's a means to an end. You (everyone), you're using it because you're writing something, not because you're trying to be seen scribbling deep thoughts in a damn moleskine notebook. |
That functionality's actually available in hg, it just doesn't seem to get used much (except by people who are being forced to use hg and want to make it just like git). The more common workflow seems to be using different clones for different branches, which has both advantages and disadvantages, as does git's approach; it seems mostly that people choose a VCS depending on which side of the tradeoff they like best.