As of today, Stack Overflow is now officially using a distributed version control system. Specifically, Mercurial, as hosted through Fog Creek’s Kiln service.
While we weren’t unhappy with Subversion, we weren’t married to it, and we needed to switch anyway so we can easily share code with the team in NYC. There’s nothing quite as corrosive to worldwide programming collaboration as being on different source control systems.
If you’re new to distributed version control, first you should check out Joel’s excellent Mercurial tutorial at Hg Init.
At this point, you may be wondering: should you switch to a distributed version control system, too?
I think you should dabble in it, absolutely, as there’s no question that it represents the future of all source control. But let’s not kid ourselves: the tools are still a bit .. raw. Particularly if you’re a GUI-loving wussy girly man like myself. We had gotten a bit spoiled by the excellence and maturity of TortoiseSVN and VisualSVN on Windows. There are Mercurial equivalents, of course:
- TortoiseHg Windows Explorer shell extension
- VisualHg Visual Studio plugin
But, as I said… raw. Raw is definitely the operative word here. DVCS hasn’t crossed the chasm yet, so if you buy in now, you’re still on the visionary edge of software development.
This can be a fun place to be, as it’s where all the innovation is typically happening, but there are … tradeoffs. Painting in very, very broad strokes — warning: massive oversimplifications ahead! — I’d say that:
- If you are still using SourceSafe, get the hell off my lawn.
- If you are unhappy with your current source control system, definitely begin researching your DVCS upgrade options. No time to get started like the present!
- If you are happy with your current source control system, read Why Git is Better than X, substituting “my source control system” with X. (While there are differences between Mercurial and Git, the differences are not hugely significant any more; they are basically the Pepsi and Coke of DVCS.) Do you see anything on this list that you feel strongly about? Does anything in this comparison directly address any daily pain points for you and your team? If so, then you should look deeper into DVCS.
There is one thing you do want to watch out for — eventually, teams adapt their behavior to the software they’re using. Without even realizing that they’re doing so. If I had to pick one word to summarize the benefits of DVCS, I’d say that word is flexibility. DVCS is way more flexible than centralized source control. So if you learn some DVCS, you might just find that it unlocks a new, more productive way for your team to “get things done”, as they say.
Subscribe via RSS
37 Comments
Congratulations on finally moving out of the hole that is svn.
My favourite part is being able to work while offline and still commit your changes.
An important point to note is that you can get some of the benefits of a DVCS today even if your employer doesn’t switch. Both Git and Mercurial have excellent integration with SVN, so you can create your own repository and tie it to your company’s SVN server. There’s a quickstart for Git here: http://www.viget.com/extend/effectively-using-git-with-subversion/
All my interaction with SVN these days is through Git, and I don’t understand how I survived earlier.
Great ! Could you tell what made you choose Mercurial and not Git ?
I’m a GUI-wuss too, but something about git made me give it a try anyway. I think it’s the simplicity of the ‘object model’ (http://book.git-scm.com/1_the_git_object_model.html) which got me interested.
And the easy branching & magic merging (and it IS magic!) got me hooked. So by the time I got round to downloading git extensions, I’d got used to the command line and git gui/gitk.
The other thing I like is that you don’t have to tell it about filename changes. Which means Visual Studio can do it’s thing, and git ‘just knows’. No stupid workarounds.
@Damien Code sharing with the team at NYC, Jeff says that in the post.
I’ve used Mercurial for about 2 years and never touched the GUI tools. The command-line is where it’s at.
@Matan: The other obvious direction would be to mandate the NYC-team to use the same VCS as the rest of the Valuable Associates.
@B Fog Creek had already moved to Mercurial after two of the smart fellows there managed to persuade Joel et al of the benefits of DVCS. Fog Creek were using Subversion before. See http://blog.bitquabit.com/2009/11/10/dvcs-as-code-review/
Its about time :) Kiln is an awesome tool and a natural progression from Subversion.
(While there are differences between Mercurial and Git, the differences are not hugely significant any more; they are basically the Pepsi and Coke of DVCS.)
Why do I only ever hear mercurial users say this? Ask a git user if git and mercurial are the same and most will tell you they are radically different.
The two reasons why Mercurial and Git are worth switching from SVN?
1. gitignore/hgignore instead of the clunky “magic metadata” that svn:ignore is
2. Proper Branching/Merging. SVN got a lot better, but having a branch as a copy always felt weird, mainly because it leads to the trinity of tags/branches/trunk and because you always have to construct/remember the URLs of the repository. All that stuff should be hidden as an implementation detail.
I don’t know how well branching in Mercurial works (I heard people recommend cloning the repo instead?), but I know that I fell in love with git after using it for a while.
Tooling isn’t even needed that much, I mainly used tooling in VS2010/Subversion to to not check in crap (bin,obj etc.) which isn’t a problem anymore with .gitignore and for Visual Diff/Show Log which works well enough with gitk.
Maybe git users are just more anal. I mean, git does come from the world where people fight over the differences between Linux distributions, ignoring the fact that not only are they all basically the same, but also that Linux isn’t much different to other unices, or even that all modern mainstream operating systems employ essentially the same concepts due to the hegemony of unix and the C programming language and standard library. Things are more similar than the are different. If you don’t believe me, compare Unix/Windows to z/OS and see how different things could have been.
Great to see you drop svn, you’ll never look back.
What sort of workflow is the SO team going to be using with Hg? Are you going to use branches or Mercurial Queues?
Branching in hg is different than git. git has the conception of pruning dirty trees. hg has the conception of never rewriting history. There are certain effects of this difference that I don’t fully understand, but the effect is that there is a different.
Joel’s tutorial is enlightening, to say the least.
The most important diference between Subversion (and other centralized VCS) and Mercurial (and other distributed VCS) is that (at least by default) centralized VCS promote update-merge-commit workflow, while distributed VCS promote commit-then-merge workflow – which is much safer. Also Subversion had and to some extent still has worse support for branchy workflow; like Linus said its ease of merging that is important, not how easy is to create a branch (fork).
SO has some answers about differences between Subversion and DVCS, and differences between Mercurial and Git.
@John: Thanks, that makes sense. And together with Joel’s tutorial and the ‘hosted by Fog Creek’-part makes going in that direction the more obvious choice of the two.
I love the comment If you are still using SourceSafe, get the hell off my lawn. What about those of us that are still using SCCS? (and by us I am in fact implying that my employer is still primarily on SCCS, with a little of RCS/CVS thrown in the mix)
Welcome to 2002.
My FOSS projects are really small, so moving to GIT or Mercurial isn’t justified. I will keep using Subversion until they grow enough and I will get more developers involved on them :)
John A.: I’m not sure if you can still buy/download it, but if you want a pretty good DVCS on top of SCCS, Sun’s old Teamware product did a pretty good job. Its major deficiency is probably that it relies on a distributed filesystem for its repository actions (meaning that both must be accessible as file paths on the system running the commands), though it’s possible to work around this.
See: http://docs.sun.com/source/806-3573/TeamWareTOC.html
It was EOL’d a while ago though, so I think you’d have to find someone with an old copy.
This will probably start a flame war, but the native windows version of git is based on a fork. It’s not part of the official git distribution. Sure it’s not that a big deal. And yeah, you can install cygwin and use an official version from that, but thats a little annoying if you’re not already using cygwin.
With things being (basically) equal between mercurial and git, if you have developers on windows boxes, many people are going to pick the one where the main project supports windows in a normal way.
Do you want to end up in a situation where some sutler bug in the fork renders your windows and unix/mac repositories incompatible?
It’s the same reason many people are uncomfortable using mono on linux for something serious. Sure it works, but it’s a bit of a second-class citizen vs .NET.
Molina, till u use branching in DVCS on small projects you will appreciate that your projects are not any small to take advantage of DVCS. I use Git on personal projects and i can tell you it awesome!
At first, congratulation to have switched to a DCVS. This will clearly be the new way to control version.
But I must say there is a *huge* difference in using git instead of Hg. I don’t believe differences between these two are like the Pepsi/Coca one.
With git you can make the work of many in branches in only one branch. Then after a long work, put each of your modification in the branch you choose.
Pratically, that mean you can work a long period of time without taking care of the DCVS. And organize the commit after you worked on many different things. With Hg it is simply not possible to do that. You have to code for one thing, then create a new branch for a new thing and work in that branch etc…
Of course this kind of work has a meaning when you’re used to have many branches (one for each bug fix, each amelioration, etc…)
There’s some discussion of hg vs. git, but what about bzr?
I’m new to the whole DVCS thing and those three are the ones I’m looking at.
Good to see we’re starting to cross the chasm!
Jeff mentions all DVCS are still a little bit “raw”. Let me add a comment about another DVCS that’s worth having a look at and it’s everything except “raw”: Plastic SCM. http://codicesoftware.blogspot.com/2010/03/distributed-development-for-windows.html.
> With Hg it is simply not possible to do that.
Um, really? I’m doing this every day with mq and histedit.
Instead of the hg init tutorial, which seems to be a tad confused about some very basic facts, I recommend Mercurial: The Definitive Guide (http://hgbook.red-bean.com/). It’s got a nice, tutorial introduction, continues into some real depth, and is available in online free-as-in-beer form or for purchase in dead tree form.
Grant: OMG thank you. Something about git on Windows *never* felt right and I couldn’t put my finger on it. It is more like a 3rd or 4th class citizen but Windows was never its focus to begin with which I find pretty ironic but that’s how Linus rolls.
The decision that finally pushed me to Mercurial was a future prospective employer using Kiln. So I grabbed the source and started compiling but I wanted SVN history during my initial imports. The headache of getting swig and python integration built when I had originally left it out made me further despise SVN. Somewhere along the 1.6 branch (not a jump from 1.5 like you’d hope), the main configure script broke the BerkeleyDB arguments so I had to research and poke until I figured out which child (apr) needed this and adjust by making my own higher level build script that built each peice accordingly I’ve only used twice now and I’ve hated both times.
TortoiseSVN is perhaps the absolute best tool I’ve ever used. TortoiseMerge is phenominal. Now that I’ve started to get used to how Hg works, the absence of branches/ tags/ trunk/, etc I can safely say I won’t be looking back into that sea of tragedy that luckily a front-end tool hid from me. Had I not been the one tasked with compiling the source I would have never known any real headache.
Jeff has outlined some of my pain points in switching as TortoiseHg and SVN are very different tools where things are not and will not be 1:1. It requires a lot of unthinking that TortoiseSVN just flat out did for me without any need to formally research. Hg on the other hand has needed a manual to guide me almost from second one which is not bad but it is the “problem” Jeff mentions on Twitter. If I have to think and research before every action, yes it does mean I am a n00b but I’m hoping at some point this will become routine knowledge. Because these tools are in an infantile stage, however, I feel obligated to keep my head “in the books” and study each change with a fine toothed comb.
I suppose that’s the price we pay for early adoption though.
The biggest difference between git and hg is that git has GitHub. Hg does not.
What a flip from http://www.codinghorror.com/blog/2008/04/setting-up-subversion-on-windows.html
Glad to see we can all change. Inspired me to make the leap to git.
Josiah> github is just a big circle-jerk for open-source fanatics. It’s irrelevant to people who need source control for their actual work.
If you want DCS, a nice gui, and are willing to pay, there is what convince Linus to start using version control:
http://www.bitkeeper.com/
["the tools are still a bit .. raw"]
Are you kidding? TortoiseHg is way more awesome than the crappy SVN tools.
Just curious what Continuous Integration and Deployment tools are used?
Cheers,
Dmytrii.