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."

Comments

Git and Mercurial?

[capnchicken]

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?

[Vanders]

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.

Re:Git and Mercurial?

[Vanders]

it would be crazy not to use Mercurial is a new project

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:Git and Mercurial?

[JohnFluxx]

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?

[Vanders]

All you have to do is set up an extra server and say "Hey, this is the central server now".

Yeah. I know. In fact I did just that at my last job when we implemented Mercurial. The problem is training developers to push their local changeset to the central repository and from stopping developers pulling from someone else and not the central repository. There was a least one incident a week where a conflict arose due to developers doing things like that which led to divergent codebases which required significant effort on behalf of one of the developers to merge and fix conflicts. I have no doubt these problems could have been fixed given time, but it was an uphill battle.

Re:Git and Mercurial?

[Rob the Bold]

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:Git and Mercurial?

[JohnFluxx]

I've worked in commercial development teams where a distributed system would not have worked, at all, due to external constraints and processes imposed by management.

What sort of constraints? Just wondering.

The backup thing though has to be joke. Every single person that checks out the code is making a complete backup.

Every single developer has a local repository with local changes. If you're doing things right your developers are only pushing their changesets to the central repository every couple of days. You have to ensure those local changes are backed up in the meantime.

Or you simply don't bother. Losing one developers 'couple of days' work usually isn't a big concern. It's common for svn users to also have several days worth of work uncommitted.

Although with git you can get people to trivially push as a branch to the server (git push origin master:mybranch) which is much more difficult in SVN.

Re:Git and Mercurial?

[RiotingPacifist]

you can do that with either centralised or distributed systems, i fail to see your point.

Re:Git and Mercurial?

[JohnFluxx]

> 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:Git and Mercurial?

[Wonko the Sane]

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.

I'm not even a coder but I already love git for getting the kernel sources. For years I have been downloading incremental patches from kernel.org but now I can update my tree with a single command. Just this weekend I installed git and cloned the kernel tree. Then I added the nouveau tree as a remote so I can try out KMS for my nvidia video cards. When I want to update my tree I can use just three commands:

git remote update
git merge origin/master
git merge nouveau/master

What's there not to like?

Re:Git and Mercurial?

[ckaminski]

coupled with its designers absolute refusal to support deleting contents from the repository

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:Git and Mercurial?

[hysterion]

I also think that going from no version control to CVS is a larger step than going from CVS to SVN, and that going from CVS to Subversion is a larger step than going from Subversion to Git

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?

[orzetto]

[Subversion's] designers absolute refusal to support deleting contents from the repository [is bad]

That is one great feature of Subversion: absolutely no way to screw up stuff that was committed. Revision control is about keeping track of stuff, any model that allows a user to remove information from a repository is a disaster quietly waiting to happen; sorry you did not understand that.

If you absolutely need to remove something from a SVN repository, you can do that with svndumpfilter, meaning you have to ask the repository's administrator. That's a good safeguard against accidental deletions.

"throwing useless things away makes cleaner code"

For "cleaner code" you just need svn delete.

Re:Git and Mercurial?

[locofungus]

There are only a few use cases where single user distributed and centralized revision control systems differ.

1. You can carry a local repository on your laptop and commit. You do not then need to sync to the master repository before continuing work there. (Typically in a distributed system there is one repository that is given the status of master - this avoids issues where two teams might be syncing amongst themselves but both are blissfully unaware that there is any other work happening in the same area of code.)

2. You can work simultaneously on two separate checkouts and commit them without having to "promote" one of them to a branch.

IMO any RCS that doesn't allow you to commit your tested and working snapshot whenever you want is fundamentally broken. Distributed systems must support this by definition[1] and any non distributed system that supports this can trivially be made distributed.

[1] Some distributed systems require you to merge when you synchronize changes. IMO merging should be separate from synchronizing

Tim.

Re:Git and Mercurial?

[JohnFluxx]

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.

Re:Git and Mercurial?

[David Gerard]

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.

Re:Perforce

[xmundt]

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

Errata

[kabloom]

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.

Re:Errata

[forkazoo]

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.

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.

Re:Errata

[Ed Avis]

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.

No they don't.

[SanityInAnarchy]

Each tool emphasizes a distinct approach to working and collaboration, which in turn influences how the team works.

Ok, yes, some tools do. For example, subversion supports trivial branching, but sucks at merging, so it encourages people to work on a common "trunk" branch. It also only supports a central server, so it "encourages" developing with a central server.

Git, on the other hand, "encourages" people to not put multi-gigabyte files in version control.

However, Git can be used to talk to an SVN repository. It can also talk to a central repository, or work purely via ssh between workstations, or with something like Gitjour, in a truly distributed fashion. Github is a strange and wonderful mutation of the two.

Perhaps, by making branches and merges so awesomely fast, Git "encourages" lots of little local branches, and keeping a neat patch history. But to sum it up:

SVN can handle large binary files and Windows better than Git, and is better integrated into IDEs.

Git is better at everything else, ever. Seriously -- 99% of projects that are hosted on SVN would make more sense on Git.

Re:No they don't.

[russotto]

Git is better at everything else, ever. Seriously -- 99% of projects that are hosted on SVN would make more sense on Git.

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:No they don't.

[SanityInAnarchy]

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:No they don't.

[SanityInAnarchy]

It has changed, somewhat -- but mostly, I think there's just better documentation.

But, for example...

Looked like you had to deal with bizarre syntax and long hex numbers for the simplest things

That is pretty fundamental to the design -- it's a SHA1 hash. It's also not incredibly difficult -- cut and paste. When your SVN revisions hit four and five digits, they don't really have much more meaning than that hash, do they?

Generally, you learn to use relative terms, instead -- for example, HEAD^ to refer to the revision just behind HEAD.

mercurial was much more straightforward

I thought so, too...

I think I tried mercurial, and then bzr, and eventually settled on Git for three reasons:

1. It's obscenely fast
2. Everyone's doing it, which has a network effect (github)
3. I can hold its data model comfortably in my head.

I should clarify that last part... Maybe some things are cryptic, and I'm sure I don't know all of the possible commands I could run -- but at a very basic level, I know exactly what's going on, just like I did in SVN.

Just for fun, here's the data model in a paragraph: There are commits. Each commit has a parent commit that it includes, except for merges, which have two parents. A branch is just a pointer to a commit.

That's it.

And knowing that, everything else starts to make sense... but it's more than I want to get into in a Slashdot post.

Re:No they don't.

[PeterBrett]

Well, except that SVN revision numbers are in order. Could you tell at a glance which of two binaries with the git SHA1 hash in the filename was newer? What about with an svn revision number?

You may wish to investigate the git describe command. For example:

[peter@harrington git (master)]$ git describe
v1.6.3.2-225-gb836490

The output contains the latest annotated tag, the number of commits since that tag, and the first 7 hex digits of the current commit hash prefixed by a "g". All the information you need to quickly or precisely identify a revision.

Documentation is here.

Re:I'd suggest Git

[CarpetShark]

I'd suggest Git too. But what I really want to know is... why does it matter *which* our project chooses? Surely IDE devs and bugtracker teams could build a decent abstraction layer so that any DVCS would work just fine with them.

I think Pida just spun-off an abstraction layer at least. Hopefully people will get behind it and put an end to these silly DVCS wars once and for all.

Besides, everyone knows language wars are where it's at ;)

"More Popular"?

[adamkennedy]

> 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.

TortoiseSVN

[ImustDIE]

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:TortoiseSVN

[Lally Singh]

Ugh, I can't stand Tortoise. It just *kills* the speed of my file-open/save dialogs. In exchange for a few labels (and not in visual studio! just the explorer) and right-click commands (hint: a menu and some dialog boxes do not constitute a GUI) I literally go get coffee when the dialog box is loading my checked-out repo.

psvn.el for Emacs, however, is an absolute dream. I see my repo (or subfolder thereof) as one dired-like list. diff, checkin/update, etc. are live and just update my buffer.

No mention of ClearCase?

[gillbates]

What I find interesting is there's no mention of ClearCase. Maybe the author is unaware of it, or considers it obsolete? Then again, the author didn't seem that experienced with the debacles into which one can get with revision control SW. The example he posits is the least of the problems which can crop up.

I've used both ClearCase and CVS. First, CVS:

1. I instinctively save files. And this is a bad thing to do with CVS; when I do a commit, my otherwise unchanged file can overwrite another engineer's more recent changes because I happened to save the file at a later date than him. The interesting thing is that this is not immediately apparent to either of us until we check out a fresh copy of the repository and he notices his changes are gone. And then I'm listed as the last modifier, and he comes to me...
2. You can't (or shouldn't) copy one directory to another within a source tree. Nor should you do it between repositories. CVS will commit your changes to the copied directory back to the original repository, unless you delete all of the CVS folders. This little quirk cost a few of my colleagues a few hours of debugging to figure out why their changes kept disappearing...
3. CVS does not (or did not when I used it) enforce strict version control protocol. I can commit an entire repository back to mainline even if I have outdated files. Even if others have made more recent updates. I didn't know this was happening for a good few months of use...

Now for ClearCase

1. ClearCase can manage extraordinarily large codebases spread across several geographical locations.
2. It can be integrated with version control and bug tracking databases.
3. It allows two or more developers to work on the same file at the same time, with the last one to commit having to perform a manual merge *only when there are conflicts*. Most of the time, it gets the merges right.
4. With proper tagging procedures, I can always reproduce the last build bit-exact. No matter how badly an engineer subsequently mangles the codebase, I can always build from the last tag. My impending release can't be sabotaged by another developer committing code-breaking-but-it-compiles-on-my-machine-oh-silly-me-I-forgot-the-headers kind of changes.
5. It does have problems with cache-coherency. Modifying files on machines other than the build machine may end up with stale files being linked...
6. It has dynamic views, which don't require a full copy of the source tree on the local machine. There are some big advantages to this, among them being not having to worry so much about the theft of a developer's laptop, and using the server's storage pool for building, rather than the local hard disk. From a developer perspective, it is nice not to have to wait an hour or so for the repository download should I need to make a change to an older codebase. I can work on multiple versions of the same code base at the same time, without having to maintain a separate local copy of the entire tree for each of them.
7. Managing ClearCase is an administrative position. Yes, it is exceedingly complex.
8. Suppose I merge several bug fixes for a build. And later, one of those fixes needs to be backed out (didn't fix the problem, conflicts with other SW, etc...). I can do that with ClearCase rather easily, without having to reconstruct all of the interim versions between the two.
9. I can apply the same bugfix to two different branches of a source tree without checking out and modifying both branches. That is, I can check the changes into one branch, and merge them into another branch (or just pick them up) without having to checkout the repository from the other branch.

Now, granted, a lot of FOSS products are not trying to be SEI level 5*. They don't have to demonstrate a repeatable process. The often don't incorporate bug fixes into older releases, or maintain several concurrent branches of the same codebase. It is also important to show which

Re:No mention of ClearCase?

[Ztream]

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?

[ztransform]

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:No mention of ClearCase?

[7 digits]

Nope. Moving directories within a checked out repository and committing their content will commit them back from where they were checked out.

His "save overwrite stuff" issue is probably due to him loading a file in his editor, updating the underlying version, and saving the file. If he uses a shitty editor, he may overwrite the changes. If he blindly commit his changes, he may have manually reverted the file. I've seen this happen with careless developers. I don't consider this a deficiency of CVS, as he actively overwrote the file. I could do that with any version control system.

His last point is wrong, though. Maybe he had some script that did some forced commit.

Clearcase.

[Ungrounded Lightning]

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:Perforce

[ZeekWatson]

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:Perforce

[hterag]

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

[SashaMan]

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.

Justin Case

[Cod33]

http://thedailywtf.com/Articles/The-Source-Control-Shingle.aspx