Re: [RFC] Linux Kernel Subversion Howto

[Larry McVoy]

On Fri, Feb 04, 2005 at 02:01:27PM +0100, Stelian Pop wrote:
> On Thu, Feb 03, 2005 at 02:28:54PM -0800, Larry McVoy wrote:
> 
> > > > 		CVS		BitKeeper [*]
> > > > 	Deltas	235,956		280,212
> > > 
> > > Indeed, for now the differences are rather small. But with more and
> > > more BK trees and more merges between them the proportion will raise.
> > 
> > Actually that's not been the case to date, it's held pretty constant
> > and in fact the ratio has gotten better.  The last time we visited 
> > these numbers it wasn't as good as it is today in CVS>
> 
> In fact I am looking at the number of *changesets*, not the sum of all
> file revisions.
> 
> 			CVS		BitKeeper
> 	Changesets:	26419		59220 (minus 6994 empty merges)
> 
> This isn't 16%, its more or less 50%, and this is the loss I was
> complaining about.
> 
> It is true that 34% of the changesets could be recreated by analysing
> the 'per file' commit logs, but the 16% are not recreatable (those
> 16% correspond to the case when someone makes several changes to a same
> file without pushing to Linus between the two).

You need to rethink your math, you are way off.  I'll explain it so that
the rest of the people can see this is just pure FUD.  

To make sure this was apples to apples I went to the BK and CVS trees
which are in lock step and reran the numbers:

			CVS		BitKeeper	% in CVS
	file deltas	210,609		218,742		96%
	changsets	26,603		59,220		44%

You are not factoring out the ChangeSet deltas, which are BK metadata, 
they aren't part of the source tree.  If you remove those then the
difference between CVS and BK revision history is 209K deltas vs
221K deltas.  

In other words, the CVS tree is missing no more than 4% of the deltas
to the source files.

READ THAT AGAIN, PLEASE.

The CVS tree has 96% of all the deltas to all your source files.  96%.  

My good friend Stelian would have you believe that you are missing 50%
of your data when in fact you are missing NONE of your data, you have 
ALL of your data in an almost the identical form.

What Stelian is complaining about is the patch set which is easily 
extractable from CVS is at a coarser granularity than the patch set
extractable from BK.  That's true but so what?  Before BK you only
a handful of patches between releases, now you have thousands.

I suppose what we could do is stick the BK changeset key into the 
delta history so that if you really wanted to get the BK level
granularity you could.  

> [describes violating the license]
> But you may consider this contrary to the 'non competitor' clause of
> the BKL (clause 3d), that's why I need some authorization from you
> before starting.

And you most certainly do not have it, as you are aware it is a
violation of the license.  Asking for an exception is about as polite as
me asking for an exception from the GPL's requirements.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/