[MPlayer-dev-eng] Fwd: Re: Sourceforge CVS, was Re: [Dri-devel] radeon error

[Arpi]

hmm.

--------- Forwarded message ---------
From: Linus Torvalds <torvalds at osdl.org>
To: Jon Smirl <jonsmirl at yahoo.com>
Subject: Re: Sourceforge CVS, was Re: [Dri-devel] radeon error


On Tue, 2 Sep 2003, Jon Smirl wrote:
> 
> Having used CVS and BitKeeper, BitKeeper is way better.

I will just add a big "Amen, Brother!" to that.

Yes, BitKeeper has license issues, and some people won't touch it. But
there are CVS/SVN gateways for that, and the kernel people (who I think
tend to be more religious about licenses than the average XFree86 person) 
seem to have finally accepted it.

And yes, BitKeeper is different enough that there is a learning curve
before you "get" the distributed nature, but once you do so, your problems
with forks are a thing of the past. Forever.

[ And the good news is that there are now a fair number of people out
  there who are getting more and more used to the distributed nature of 
  BK, so the learning curve might not be as painful as it used to be. If 
  only because there are now more people who can help. ]

I can also say that bkbits.net has been well maintained and responsive 
when there have been issues. And the nice thing about true distribution is 
that you are _not_ dependent on one single site anyway. bkbits.net has 
just been a very convenient one - but the fact that we don't have to 
absolutely _rely_ on it still makes everybody just so much more confident 
about it.

For example, when bkbits.net has had downtime (they had some disk problems
at some time) that doesn't mean that development grinds to a screetching
halt. Not only are all the private repositories still fully functional,
but you can always merge between them through other connections even if
one central site is down.

The merge tools are also very cool, and the speed of updates (assuming you
have enough memory in your machine - BK does tend to want to have lots of
RAM for caching the tree) are much better than CVS.

As an example of _why_ BK is so nice , I did a merge demonstration for
Dirk Hohndel (some of you may still remember him ;) a few weeks ago, and
showing how fast a "bkr diffs -u" is (full current "pending" changes in
your tree).

Dirk commented that he used to consider that a "go away for a cup of
coffee" operation. With BK it is _instantaneous_ if you have the tree
cached, and takes about 8 seconds on a cold cache tree for me (and that's
with the kernel tree, which is quite a bit bigger than the DRI tree).

And doing the equivalent of a "cvs update -d" (ie "bk pull") usually takes
just a few seconds.

So if you can get over the learning curve, over the license (and - for
some people - over Larry McVoy's personality), then BK is really a 
wonderful thing.

			Linus



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel