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."
Git and Mercurial are more popular than Subversion? That's the big news to me, with all snarkyness aside. I best be getting out of my bubble.
A libertarian shat on my carpet once. Claimed the free market would sort it out. -Ford Prefect(8777)
P4 is awesome and works great for huge repos with lots of developers.
However it is getting stale. I can't think of a single new feature added to it since I started using it in 1999.
Greetings and Salutations...
Funny...I tend to think of software more like a truck than a stalk of celery, so, staleness really never popped up on my radar. What new features would add to the capabilities of a package that you describe as "awesome"?
Not flaming, I am really curious, as I have done some software development myself, and, wonder where the line is between actually adding good functionality to a tool, and "creeping featuritis" that adds bells, whistles and complications, but no real increased usability.
regards
dave mundt
YAB - http://blog.beemandave.com/
Well except for VSS, and Microsoft isn't even dumb enough to use that on their own projects.
This article was very limiting by only talking about a few small system, didn't even talk about "interesting" systems like ClearCase (Yes, you too must hire a Clear Case administrator to figure out this beast). I really liked the underlying technology where the VCS was treated as a filesystem driver and the current code that you were working on was handled as a set of operations on the file system.
I have mod points and I am not afraid to use them
> Today, leaders of teams are faced with a bewildering array of choices ranging from Subversion to the more popular Git and Mercurial.
I think you might be confusing Internet "buzz" with popularity.
Yes and no. It is possible to only update/checkin at a certain level in the directory hierarchy, and miss a change to a header outside of the scope you are interested in. You have to be slightly beligerent to get into such a situation, but it can happen.
I am a bit jealous of some Git features, but the place I work -- and me for my personal projects -- use SVN for one big reason: TortoiseSVN. It is a great interface to version control and not everyone (probably the majority) who needs to contribute is a programmer, or has any idea about command line interfaces, ssh, branching, merging, etc.
I am aware of TortoiseGit, but it has not reached a stable release, so it is not up for consideration in a serious environment.
There are other things to keep in mind too; SVN is much more tailored to our repo structure than Git, so that's a big plus for SVN -- at least for us.
Kind of. I think what the author was getting at is that if SVN doesn't detect a conflict, it will perform the merge and won't /force/ you to look at the file before committing. So, you can wind up with Bob calling function foo in his checkin while Alice deleted foo in hers, or more subtle errors.
It's still Alice's fault for not checking that SVN did the merge right, but that's not much consolation.
I've only tried a few revision control systems.
Of those I've tried, Clearcase is the hands-down winner function-wise, especially for the diverge-converge model of multi-programmer development.
Extremely lightweight branching. "View spec" - a little language to specify exactly what version of what you want: (Version x.y.z but override by the foobar feature development branch but override that by anything in /src/garble as of Tuesday at 3:15PM but override all with anything I've got checked out in MY development branch...). Integration into the filesystem so your tools "see" containing just what version of the sources you specified. A make variant that imports already-built objects that some OTHER developer made from the equivalent sources, rather than compiling them again, etc.
Downside: It's commercial and 'way pricey.
But if you're a commercial shop you should at least evaluate it. The functionality is fansastic.
(I hear some of the core functionality came from an open-sourced student project. I've often wondered why there isn't a FOSS clone of the important features - or if there is and I just missed it.)
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
I use Subversion on a daily basis, and I believe everything positive you said about ClearCase holds true for Subversion, except point 9. There are some philosophical objections to 9 (you should test the resulting code before committing it anyway), but I don't know if it's a design decision or a missing feature.
That's not to say that Subversion doesn't have problems of its own though, but using CVS as a representation of the state of version control systems is like judging proprietary software on the basis of Windows 95.
Essentially everyone who knows anything about modern version control considers CVS obsolete.
Clarification: everyone who thinks they know everything about modern version control considers CVS obsolete.
CVS still has advantages, in my opinion:
- simple underlying storage structure that any administrator can understand
- ability to simply administratively repair obscene or damaging check ins (investigate the cvs admin -o command, few other version control systems can do this)
- simple file numbering scheme
At the end of the day your needs may be more complex (regular branching, regular directory moves, etc) but in some commercial situations simplicity and ease of administration can be valuable points (and I think often outweighs the perceived benefits of SVN).
As for Git with it's advanced learning curve of at least a week, sometimes you have not just programmers contributing to a project but front-end designers, template producers, who have never seen a version control system in their life. Subjecting them to Git can be both cruel and potentially uneconomic - particularly if they are all on short term contracts.
No, the statement is quite correct. (And your statement 'Subversion requires you to update... whenever you have modified a file that has changed' is also correct.) Suppose the repository contains two files foo.h and foo.c. Bob modifies foo.h and checks it in. Separately, Alice modifies foo.c and checks it in. Subversion does not require her to update her working copy first; she can check in the file without any warning. But now the server has a new tree that doesn't match either Bob's tree or Alice's tree. They could both have run the test suite before committing and seen it pass; but the current version on the server might fail. (For even more concreteness, suppose foo.h defines an unused constant 'const int FOO_FACTOR = 5'. Bob checks in a change to remove it. Alice, meanwhile, edits foo.c and starts using FOO_FACTOR in the code. Both people are checking in working code; both Bob's tree and Alice's tree are working programs. But the state that ends up on the server is neither of those, and is a program that won't build.) I am not saying this is good or bad, just saying this is how Subversion works.
-- Ed Avis ed@membled.com