Version control poll!

I voted for mercurial because I am a Python weenie. I have a particular hardon for it today because I just found out about http://www.selenic.com/mercurial/wiki/index.cgi/RecordExtension.

How many of these have you used yourself?

I guess it's a difficult poll. I've been doing this a long time and yet have only used RCS, CVS, PVCS, Soucesafe and Subversion. Two of these aren't in your list, although I wouldn't worry, as they are shite (CVS is derived from RCS and on the face of it, PVCS seemed to be too).

Nonetheless, I kind of have never cared too much. People always beef about Sourcesafe, but it never caused me any problems. I mean, it's not amazing, but it was hard to see why CVS was much better. Subversion is the best of what I've used.

What would I expect to see in these more amazing source control systems. The Linux guy's always batting on about Git and how it seems to be able to do magical merges without you having to even look at them. I find this hard to believe given that diffing is a non-trivial problem with an ill-defined solution.

What's so good about Mercurial?

Oh I suppose I used the IBM one that used to come with their Visual tools. Which was OK too. Apparently it was really clever - but it was too clever for most people who used it.

Not mentioning ClearCase is like talking about PC software and omitting Microsoft.

(Voted Perforce.)

Talking about PC software and omiting Microsoft is pretty much what everyone under the age of 30 or so does these days, but I'll assume that's not what you were getting at. How irrelevant Microsoft has become

I like to think I know what I'm doing, but I've never worked in a corporate environment. This might explain why I have never even heard of ClearCase. I haven't used Windows since 1998 though, so that might have something to do with it too.

I've used CVS, SVN, mercurial, darcs. darcs was pretty cutting edge five years ago, and I enjoyed use it, but the dependencies (you had to compile a Haskell compiler before you could compile it on OS X) meant I had nobody to play with.

For my money, the key advantage of git (and Mercurial, darcs and Bazaar) is that they are distributed. A related but distinct advantage is that they are not Subversion. Non-free and not available on OS X and Linux are both show-stoppers for me, so I never even looked at Perforce. I migrated from Subversion a couple of years ago before git had got going (possibly before it even existed).

I understand git can work as a Perforce client. I've never actually used it, but reading these two is what got me thinking about version control:
http://osteele.com/archives/2008/05/my-git-workflow
http://tomayko.com/writings/the-thing-about-git

"Talking about PC software and omiting Microsoft is pretty much what everyone under the age of 30 or so does these days, but I'll assume that's not what you were getting at. How irrelevant Microsoft has become"

I think I forgot this paragraph. Should have said:

Talking about PC software and omiting Microsoft is pretty much what everyone under the age of 30 or so does these days, but I'll assume that's not what you were getting at ; ) How irrelevant Microsoft has become in the past couple of years is something for another thread though. There's a Joel on Software post about this I'll try to dig up.

Sourcesafe problems (I have no idea if these criticisms hold any water):

http://www.highprogrammer.com/alan/windev/sourcesafe.html
http://www.developsense.com/testing/VSSDefects.html

There area a lot of point to catch up on here, but what I can say right now is that we successfully used Sourcesafe to manage branches over ten years ago in a product that is sold to the world's major aerospace companies. The criticisms may or may not hold up, but my experience was that Sourcesafe was as good/bad (there's no way of measuring these things) as the competition at the time.

I'll read it more tomorrow, but the term "distributed" seems very weak. As far as I can tell (so far), it's technically the same as other source control systems but enforces some kind of meritocracy on development.

To me, distributed would just mean "client-server", e.g. if I do a diff, instead of getting the two files to my computer and diffing them, it would diff them and send me the result of that diff.

I would have to say that now that I've read this stuff through more clearly, I still can't quite figure out what fundamentally the difference is; well, at least to the end user.

Let's assume SourceSafe has some problems. I wouldn't choose to use it. My point really was that for all the time I used it, compared with all the time I used CVS, there were just as many problems. Still, they are all about as bad as they get for source control systems. What I'm interested in is if there are some things that are lots better. For me, all Subversion really does that I like is use transactions to do commits, so I know that either all of it will be committed or none of it will be, which I kind of like to know; at least what's in the source control system is consistent.

I've never used ClearCase myself, but it's certainly widely deployed. I've done an interesting job of avoiding it. CM Synergy has an interesting model, but by all accounts in practice it doesn't work very well.

"Not being Subversion", I don't buy as an advantage. You'd have to explain why just being Subversion makes it bad (or worse, or whatever).

Now on to the key stuff... That Wikipedia article is extremely poor. What I was looking for are advantages and disadvantages, but the quoted advantages either seem to pretty much apply to the likes of CVS too, or they are not really an issue (e.g. 'allows private work' - my amazing hard drive allows me to do that!). The disadvantages are even worse - they aren't actually disadvantages of these type of SCM tools; they say (several times over) that the reason people don't use them is because they're stupid or intransigent.

Now, I may soon push for us to make a change from CVS at work. It's a big undertaking as there are 500 or so developers, but CVS really isn't cutting it these days, and I'd like to move to the right thing. Subversion is the most likely choice at the moment, but I'd love for someone to convince me that something else is a better thing to do, but that Wikipedia article seems to be extremely thin on facts.

Eh, Subversion. I'm boring.

The Ruby guys here really love the (local) branch model of git. "Every new feature is a branch" Being able to change branches within a working copy is pretty great too. Check out github btw

I don't understand how even with ancient source control systems that logically, every feature is a new branch anyway, I mean, by editing your files on your computer, you are basically creating a new branch. What's the difference? I must be missing something.

For sure I think I must be genuinely missing something here. Normally I'm confident enough that it's just the industry talking toss, but here I can't see that this many people would praise something without there being some value, but I don't see it. Can someone explain?

(e.g. 'allows private work' - my amazing hard drive allows me to do that!)
Yes, but git allows you to commit offline -- instead of yr repository being on a server, it's stored locally, so you can do everything you would -- branch, merge, commit, revert etc on your ownsome, and if you want it stored somewhere else, you push it up to them.

I prefer that to subversion because I can make my local sandbox a total pigsty without the "good" server copy becoming a mess as well. I imagine that'd be handy if you were dealing with lots of developers too -- they can have local branches, then merge back and push. Or other people can pull from their copies to work on their changes, etc.

There's a guy at work, who is a total genius, and his three questions are:

- So what?
- Who cares?
- Why now?

And what I can't figure about the being able to "commit offline" (which I'm not sure what means) I think I would ask the first two questions about. Can't you just not pollute the repository by kind of not committing?

By committing offline, I mean you can be entirely offline -- no connection to the server at all -- and still have the full version control set of commands going on. When you commit, it's not sent to a remote server, it's just incorporated locally.

That's where it's different from polluting the repository simply by not committing: you can do lots of commits, reverts etc, but it doesn't affect anyone else or the repository (though there isn't really such a thing under git) until you push those changes out.

So what?

Sorry. Just asking the question. What's good about that? How does it make it so much better?

The guy who asks these questions reported to SD we were talking about earlier... He's a switched on guy.

Well, under subversion if you're not polluting the repository by committing, you're left to basically do your version control by hand -- if you don't commit to the server, your changes aren't being stored so you can't revert. With git you can snapshot your state at any time, revert to it, and so on, all in private. xp

Oh OK, assuming your development environment doesn't let you roll back stuff, then that would be true. I suppose Deano doing vim development would appreciate this.

and all the RoR/Textmate crew :)

That's true. There are lots of tools that would help them out.

But I suppose it would result in just developing the same things but in a different place. It probably is inevitable. I've come to conclude that people don't learn from history.

Automatic thread bump. This poll is closing tomorrow.

Automatic thread bump. This poll's results are now in.

version control is ~great~

> I suppose Deano doing vim development would appreciate this.
> ― Keith, Saturday, 2 August 2008 01:30 (3 years ago)

you what what?