Making Sense of Revision-Control Systems 268
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."
Many choices, not mentioned here. (Score:1, Interesting)
There's a brief mention of perforce (and then nothing after it). There's mention of CVS but it's dismissed [rightly so!] as old. This is JUST about svn, git and hg. No bzr, vss, darcs, arch, monotone, bitkeeper, clearcase, or visual studio team server. Now, maybe that's a good thing, maybe not, but the summary made me think they were going to deal with a range of revision control systems. They picked three. Oh well. :)
Re:Git and Mercurial? (Score:5, Interesting)
Re:No they don't. (Score:5, Interesting)
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.
Re:Git and Mercurial? (Score:3, Interesting)
> Using a distributed system such as Mercurial would have made this near impossible as there would be no way to stop someone cloning a developers local repository.
How is that different from just copying a developers svn copy? You wouldn't get the history, but you would get the code...
The other things are also possible. See git pre-commit hooks.
Re:Perforce (Score:2, Interesting)
Off-line development is the first thing that come to mind.
Its also single-centrally managed server, which is painful for distributed development (but perhaps good for companies). There is P4Proxy, but that is readonly. Remote users on the other side of the world don't have the best experience.
I could list many other things. SCM has grown significantly since 1999, P4 hasn't.
Re:No they don't. (Score:3, Interesting)
There is an occasional conflict, but you can't always avoid that.
Git avoids that a lot better than Subversion does. Yes, there's an "occasional" conflict, but much more rarely.
Call me a die hard, but I wouldn't trust Subversion's automatic merge feature. I do it all by hand
Yes, I've done that...
Doing it all by hand sucks -- it's a lot of manual effort to make sure you know exactly what you should be merging, and it still takes far longer to do that. Doing it with SVN's merge tracking sucks -- we had it to where it was taking half an hour, and could still fail.
I mean, I liked the model. I liked having a deep understanding of what it was doing.
But even by hand, even trying to disable all the merge tracking stuff, it still took minutes. And that's after doing the 'svn log' myself, trying to figure out exactly what should be merged...
In Git, I haven't found an operation that takes longer than seconds. Having five branches per developer is actually a perfectly sane and workable situation on Git -- having one branch per developer was a nightmare in SVN.
I doubt that anyone who's actually used a modern SCM can say with confidence that SVN merging doesn't suck. Half an hour for SVN vs one second for Git.
Re:Perforce (Score:2, Interesting)
P4 is fast but don't be mistaken it too has some reasonable failings
is performance/reliability is terrible over a WAN
lacks an integrated secure communicaiton system
no disconnected operation
no archive/shelving operations
Savana - transactional workspaces on top of SVN (Score:4, Interesting)
Friends of mine have open-sourced savana, http://savana.codehaus.org/ [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.
Re:Git and Mercurial? (Score:3, Interesting)
But that's only a 'legacy' problem. Today, going from no version control straight to Git/Hg is much easier than even your first step -- and saves you from having to unlearn all that intermediate junk.
Re:Git and Mercurial? (Score:3, Interesting)
If you want a policy that everything has to be in branches, then you can do that in git. In fact it's much easier in git than svn.
> What it boils down to is that a distributed system allows a developer to go hide in a cave for a while whilst under the illusion that stuff is safely checked in.
With SVN, a developer can go hide in a cave for a while without ever committing stuff. What's the difference?
The part about committing as early as possible doesn't really make sense to me. If you have two group with large changes, then git allows those two groups to merge with each other, making it easy to catch problems _before_ merging with head.
That is something SVN just cannot do.