[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC] Linux Kernel Subversion Howto
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
Changesets: 26419 59220 (minus 6994 empty merges)
This isn't 16%, its more or less 50%, and this is the loss I was
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).
>> It is a bit difficult to get it right wrt renames, deletes etc, and
>> it can take quite a while to execute, but 3 man month work is a bit
> I stand by the 3 month number.
If all that bothers you is the amount of work implied, I have an idea.
I could write a script which does use BK and exports the metadata into
CVS (or SVN directly), without losing any changeset information. I'll
do this for free.
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
Also, I won't work on that if I cannot distribute the result of my work.
The distribution of the metadata is contrary to the 3 (g) clause in bkl,
so I need your authorization to distribute the resulting CVS (or SVN)
Note that for the distribution it doesn't need to be me, it could be a
third party who would run the script and distribute the result
(kernel.org, osdl, Linus himself etc), or it could even be you if you
want to be in control.
How is that ?
> As a business strategy it was foolish. But it wasn't a business decision,
> it was a choice that I made because I wanted to help Linus.
> And it worked. That ought to have some value in your eyes.
It has and I don't question the use of BitKeeper for the kernel
development, as long as it is useful for it (and it is !) and as
long as the data (with the metadata) is also available outside of BK.
> enough to respect our terms.
If I didn't respect your terms I wouldn't ask for permission to do
what I want to.
Stelian Pop <stelian@xxxxxxxxxx>
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/