Re: git versus CVS (versus bk)

On Sun, 30 Oct 2005, walt wrote:

-91 was the first version. It was usable (depending on your definition of "usable" ;) in early -92.

It's really not very easy to explain why CVS sucks. After all, sometimes people who have used it for decades have a hard time understanding the suckiness.

I've used CVS for "real work" at Transmeta, and hey, it worked well enough. When you have groups of just a couple of tens of people max, and very strict rules on how to do things, and you trust everybody, CVS works fine. It starts to really show its problems whenever you need to work remotely, but there are things you can do to make the pain less.

A lot of CVS people will tell you that it sucks because it can't do renames, and because certain operations take forever (tagging etc). That's only superficially true, and it is really a suckiness that comes from some implementation issues.

SVN fixes (supposedly) those "implementation suckiness" issues. It does so largely by doing a much better database, which allows it to do certain things much more efficiently. Personally that part scares me, since I think it's also a much more fragile setup and there's apparently been people who lost their entire database to corruption (something that is very hard to do with CVS, since the "database" is so weak), but that's a different issue.

But the things that SVN fixes are not the things that really matter in the end. SVN i sa better CVS, but it still has all the basic fundamental problems. Namely the fact that it's centralized.

The problem with a centralized model is that there's one point of contact: you can replicate the central database endlessly, but you can only really modify it in one place. Which means that anybody who wants to modify anything at all needs to have write access to that one repository.

Now, you can limit write access in various ways ("user xyz can only write to these files"), but it still requires an a-priori trust network rather than a dynamic one. So every single CVS project (and SVN does zero in this regard) always ends up having politics around the question of who gets commit privileges, and what the rules for them are.

So one of the worst downsides of CVS is _politics_. People, not technology.

The other implication of centralization is the fact that it means that you can't do any off-line work. You need to be able to access the central database in order to do real work. You can replicate the repository and try to take it with you and then back-port whatever changes you did when you come back, but more commonly it means that when you go off with a laptop, you're either in read-only mode, or you need to have an internet connection whenever you want to do development. That's just nasty.

The upside of centralization is that a lot of things are easier. Easier to think about, easier to get a stupid and straightforward idea working.

But if you have hundreds of developers, and you have a dynamic trust network (I trust some people, they trust others, and we all tend to trust people more or less depending on what they work on), the CVS model is absolutely HORRID. It just doesn't work.

Git does all of that right. So did BK, for that matter. There's no a-priori "these people can commit", because there's no central database. There's no problem with off-line work, because every repository is totally self-contained and independent of every other one.

			Linus