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
Because Subversion offers working out of a shared branch as the path of least resistance, developers tend to do so blindly without understanding the risk they face. In fact, the risks are even subtler: suppose that Alice's changes do not textually conflict with Bob's; she will not be forced to check out Bob's changes before she commits, so she can commit her changes to the server unimpeded, resulting in a new tree state that no human has ever seen or tested.
This statement is incorrect. Subversion requres you to update your working copy before committing whenever you have modified a file that has changed in the repository.