Slashdot Mirror
Making Sense of Revision-Control Systems
ChelleChelle writes "During the past half-decade there has been an explosion of creativity in revision-control software, complicating the task of determining which tool to use to track and manage the complexity of a project as it evolves. Today, leaders of teams are faced with a bewildering array of choices ranging from Subversion to the more popular Git and Mercurial. It is important to keep in mind that whether distributed or centralized, all revision-control systems come with a complicated set of trade-offs. Each tool emphasizes a distinct approach to working and collaboration, which in turn influences how the team works. This article outlines how to go about finding the best match between tool and team."
I share your scepticism. Given the vast numbers of CVS repositories that exist and the ease with which you can transition to Subversion, I don't think it's popularity is going to wane any time soon. It also has some of the widest range of plugins for IDEs such as Visual Studio and Eclipse and the largest number of tools and clients, which make it a popular choice for a lot of new projects. Outside of Linux development Git is almost unheard of, but may gain popularity and although I've worked with Mercurial professionally I've yet to see it used anywhere for Open Source development, yet.
Syllable : It's an Operating System
When I first looked at git, it wasn't even clear how simple revision control tasks could be done, e.g. simply checking in a file, or reverting changes to it. Looked like you had to deal with bizarre syntax and long hex numbers for the simplest things (and it's not just because it's distributed, as mercurial was much more straightforward). I assume that's changed as people aside from Linus actually use the thing, but it was very off-putting in the beginning.
Friends of mine have open-sourced savana, http://savana.codehaus.org/ a thin layer on top of Subversion that makes it easy to do all work in private branches before promoting to the trunk. A common workflow is:
sav createuserbranch mybranch --calls svn copy under the covers to create user branch named mybranch ... normal checkins using svn commit go to YOUR private branch ... when you are ready to promote your changes back to the trunk:
sav sync -- pulls in any changes made to trunk since your private branch was created so you can test locally
sav promote -- merges your changes back into the trunk
The thing I like about this thin "workspace managing" layer on top of Subversion is that for the most part you can take advantage of existing tool support for subversion (like integrated IntelliJ Idea and Eclipse support), as all of the savana commands just call svn commands under the covers.