[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC] Linux Kernel Subversion Howto
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
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/