I’ll admit it took a while to convince me of the merits of decentralised version control. But after a really nasty couple of merges, enough was enough. We’ve dropped SVN in favour of Git – which seems to be the biggest contender.
The main selling point for me was that it keeps track of all the metadata surrounding merges – information which SVN forgets about, requiring you to document your own merge metadata in commit messages, and scour the SVN logs trying to figure out which changesets have already been merged, when, whence, whither, by whom.
Other wins:
- It’s really fast
- Easy creation and painless switching between local ‘topic branches’, which you can create for each feature you’re working on and merge into eachother easily
- Easy to swap work-in-progress patches with other developers without having to commit to a centralised trunk
- Easy to make lots of quick local / offline commits, which you can later crunch down into one whn merging, if you want
- Have the whole history available locally, and lots of backups of the repository
Some minuses:
- The git-svnimport tool appears slightly buggy. Don’t count on it to import your SVN branches properly, especially if you moved them around at any point in the SVN history. In our case the branches it created only contained the files which had changed since the branch was created in svn – rather than fiddle around sorting them out, I just deleted them and re-created them from the git master branch by applying an svn diff. Which is OK if the history of your branches isn’t super important, but less than ideal otherwise. I also found that a small number of files were missing from the trunk, and had to be re-added manually – I suspect git-svnimport gets a bit lost when files have been moved around in non-trivial ways in the SVN history.
- There is something of a learning curve with Git, especially when it comes to more complex merging, branching, tagging, cherry-picking tasks which were the reasons I first wanted to move to Git. I found this set of lessons learned helped a lot, ontop of the ‘Git from SVN’ tutorial. Once you know what you’re doing though, it’s faster and a lot less fiddly at merging than SVN.
Did you look at darcs when you were evaluating other version control systems? I came across it while researching Nitro. It’s decentralised, like git, handles patch creation and cherry-picking really well, and is based on a really solid theory (the author is a physicist). The automatically-calculated patch dependencies mean that repos don’t even need version numbers (don’t know if this is true of git or not).
I believe it has really good svn bridging, but I haven’t tested that – I will be using it for my own work, and my current employer is only just about to make the move on the last project from Source Shredder to SVN, so I doubt they will want to go trying anything shiny and new-fangled just yet.
Yep, I’m using darcs myself on a side-project actually. It is very nice. Written in haskell with an algebraic treatment of patches as you say.
It gets very slow on bigger repositories though, I hear. I think because it treats a revision just as a big algebraic expression involving all the patches up to that point, it gets slower as the history builds up? May be wrong. But yeah, git is very very fast – written in C by Linus Torvalds. Under the hood it has quite a nice graph-based model, and doesn’t have linear revision numbering either – commits are identified by SHA1 hashes which are sensitive to the entire history up to that point.
Darcs cherry-picking is better though, and gets major points for being written in Haskell
But perhaps not as widely-adopted outside the haskell community, and tool support isn’t quite so hot. Git’s being used for the linux kernel, so you can pretty much count on it to be maintained well…
It can get a lot slower – yes. It takes quite a while to fetch the whole Nitro repo. You can use “tag –checkpoint” and “get –partial” to create a snapshot patch you can get quicker, but I haven’t done any benchmarks or anything. There are also a couple of exponential-time algorithms hidden in there, although I believe that new algorithms have been devised, but not fully implemented.
> Git’s being used for the linux kernel, so you can pretty much count on it to be maintained well…
You mean maintained well like the linux kernel, right?
Don’t know if you’ve seen this interview: http://osdir.com/Article2571.phtml David Roundy says there that he’s had a lot of developers add to the project as an excuse to use Haskell, and some even learned the language so they could contribute. Sounds a lot like Ruby/Rails was a year or two ago (and still is to an extent.) The rise of functional programming may be upon us!
Ah interesting stuff.
If you’re interested in the rise of functional programming on the web, this framework may be worth looking at:
http://liftweb.net/ (previously http://scalawithsails.com/why.html)
and the language (a true functional / object-oriented hybrid language – think somewhere between OCaml, Java and Ruby – very nice stuff, with a powerful type system and type inference, reasonably familiar/friendly syntax and everything. Runs on the JVM and works with existing java libraries).