Re: git versus CVS (versus bk)

On Mon, 31 Oct 2005, Johannes Schindelin wrote:
> 
> How about adding the whole explanation as
> 
> 	git/Documentation/howto/tell-why-cvs-sucks.txt
> 
> (maybe with some more polite name)?

Hey, if somebody else does it, that's fine.

I'm personally _so_ biased against CVS that I'm not neutral. I really hate 
the thing. I'd much rather use tar-balls and patches than CVS: I think 
"quilt" ends up being much nicer in many ways than CVS can be.

So feel free to take my explanations and write something up. I just don't 
want to do it, because I fear I might be unfair to CVS (well.. I'm 
personally 120% convinced I'm not, but still, there's a lot of people who 
actually _use_ it, so..).

> Also, I´d like to add that CVS branching/merging is no good:
> 
> <tryingtoputonalbertsshoes>
> 
> Sometimes a developer gets an idea, or the need, to implement a certain 
> feature to a piece of free software. Now, this idea might seem good, but 
> it might take a while to
> 
> 	- implement it,
> 	- flesh the bugs out, and
> 	- maybe realize the idea was not all that good.

[ details deleted ]

Yes. I consider this to be part of the centralized/distributed issue, but 
it's worth talking about. A distributed system automatically implies that 
you can have "throw-away branches" for testing, and you can combine two or 
more of these test-branches without ever disturbing (or even _notifying_) 
the "real development" branch.

In a centralized system, any branches will always be in that central 
repository, so you can't do throw-away stuff without affecting everybody 
else. Maybe the actual _code_ won't be in the "real development" branch, 
but you're writing and affecting the same repository where the development 
happens.

Again, you could replicate the whole repo, and do things there, but then 
you can't ever merge again, which in effect makes the small branch a big 
fork. So in that sense the CVS/SVN mentality basically encourages forking 
and discourages working together. This is more of the same thing that I 
alluded to when saying that CVS inevitably leads to "politics" - having a 
central place means that you have people who fight for control over it, 
even when they'd otherwise _want_ to cooperate.

With git (or with BK, or any truly decentralized model), you just make 
your own repo, do your development there, and you never need to ask for 
permissions from the central repo people. If the development works out, 
you just ask people to merge back. And if it doesn't, you don't even have 
to tell people what a total failure you were.

So with the distributed model, you don't have to publicly humiliate 
yourself when you do something stupid. Similarly, you don't have to 
publicly prove that you're "good enough" before you can play in the 
sandbox. In other words, there's no need for politics and egos.

(Now, obviously, when you've actually done the work, if people recognize 
that you're a mental giant, they'll be more likely to merge with you, and 
you'll generally have an easier time. So I'm not saying that a distributed 
model takes away the need for showing how good you are, but it doesn't 
make that a central pre-conception).

			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