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?

[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?

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

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]

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.

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.