-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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
