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."
Git and Mercurial? (Score:4, Insightful)
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.
Re:Git and Mercurial? (Score:3, Insightful)
Mercurial is a distributed system, Subversion is centralised. They suit almost totally different workflows and teams. If you're a large group of Open Source developers in different countries and timezones Mercurial may suit you. If you're a small group of developers in the same office doing rapid development, Subversion may be better for you.
Re:Perforce (Score:5, Insightful)
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
Re:Git and Mercurial? (Score:2, Insightful)
This can only be said by someone that hasn't used a distributed system.
Even if you are the only coder, a distributed system is still better since you're going to have your version, and the version on the server, and you want to be able to play about with your local version before pushing to the server. That's the sort of thing that git/mercurial are excellent at.
Re:Git and Mercurial? (Score:1, Insightful)
I used Mercurial (& CVS) in my last job. Prior to that I was a Build Engineer & SCM administrator, using Subversion, CVS, VSS (Oh God) and a little Perforce.
Distributed systems like Mercurial are nice but they do not suit every development style. A large scale commercial development team, for example, is much more likely to be structured in a way where Subversion would be a better solution. That doesn't even begin to cover things like the vast number of SVN plugins & clients for all sorts of IDEs and editors, effective backups, build management and possibly other minor issues depending on the team and the organisation.
Version Control Systems all have one thing (Score:1, Insightful)
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.
"More Popular"? (Score:3, Insightful)
> 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.
Re:Errata (Score:4, Insightful)
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.
TortoiseSVN (Score:4, Insightful)
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.
Re:Git and Mercurial? (Score:3, Insightful)
This can only be said by someone that hasn't used a distributed system.
Even if you are the only coder, a distributed system is still better since you're going to have your version, and the version on the server, and you want to be able to play about with your local version before pushing to the server. That's the sort of thing that git/mercurial are excellent at.
Wouldn't distributed and centralized version control degenerate to the same thing in the case of a single user? I've never used a distributed system, what difference would there be in that case?
Re:Errata (Score:1, Insightful)
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.
Re:Git and Mercurial? (Score:4, Insightful)
you can do that with either centralised or distributed systems, i fail to see your point.
Clearcase. (Score:3, Insightful)
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.)
Re:Git and Mercurial? (Score:1, Insightful)
That's like saying C is a bad language because it allows you to use both underscore_names and CamelCaseNames in the same program. If your developers don't follow your development policies and problems result then it's their fault and not the fault of the tools.
Re:Git and Mercurial? (Score:5, Insightful)
I don't necessarily disagree with you, but in places I've worked, if we removed code in such a fashion and an audit found out about it, we'd get pummeled. Especially if it was discovered after a public release. It's one thing to ship code copyrighted by someone else, it's something completely different to go about covering up the fact.
So I'm torn on this "feature."
Re:No mention of ClearCase? (Score:4, Insightful)
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.
Re:No mention of ClearCase? (Score:4, Insightful)
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.
Re:Errata (Score:2, Insightful)
Re:Git and Mercurial? (Score:3, Insightful)
I disagree. CVS/svn worked well in my last workplace in two use cases:
1. A project which largely has a single developer working on it. (Lots of those.)
2. Something with several developers, but very slow code changes and much discussion before even those. (Much of the stuff us sysadmins were doing.)
Any version control is a vast improvement on none, and svn is fine at being svn. But it's the last of its line.