From: lm@bitmover.com (Larry McVoy)
To: Stelian Pop <stelian@popies.net>,
"H. Peter Anvin" <hpa@zytor.com>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC] Linux Kernel Subversion Howto
Date: Fri, 4 Feb 2005 08:06:31 -0800 [thread overview]
Message-ID: <20050204160631.GB26748@bitmover.com> (raw)
In-Reply-To: <20050204130127.GA3467@crusoe.alcove-fr>
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
next prev parent reply other threads:[~2005-02-04 16:07 UTC|newest]
Thread overview: 111+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-02 15:54 [RFC] Linux Kernel Subversion Howto Stelian Pop
2005-02-02 16:15 ` Lethalman
2005-02-02 16:37 ` Lethalman
2005-02-03 10:34 ` Stelian Pop
2005-02-02 21:47 ` Daniele Venzano
2005-02-03 10:45 ` Stelian Pop
2005-02-04 20:04 ` Daniele Venzano
2005-02-04 20:52 ` Olaf Dietsche
2005-02-09 5:19 ` Kevin Puetz
2005-02-09 8:58 ` Miles Bader
2005-02-09 13:44 ` David Roundy
2005-02-03 0:29 ` H. Peter Anvin
2005-02-03 10:24 ` Stelian Pop
[not found] ` <200502030028.j130SNU9004640@terminus.zytor.com>
2005-02-03 3:34 ` Larry McVoy
2005-02-03 16:45 ` H. Peter Anvin
2005-02-03 19:32 ` Stelian Pop
2005-02-03 20:20 ` Larry McVoy
2005-02-03 22:00 ` Stelian Pop
2005-02-03 22:28 ` Larry McVoy
2005-02-04 13:01 ` Stelian Pop
2005-02-04 16:06 ` Larry McVoy [this message]
2005-02-04 16:22 ` Roland Dreier
2005-02-04 21:53 ` Stelian Pop
2005-02-04 17:03 ` Stelian Pop
2005-02-04 18:39 ` Larry McVoy
2005-02-04 20:05 ` Stelian Pop
2005-02-04 20:11 ` Larry McVoy
2005-02-04 21:40 ` Stelian Pop
2005-02-04 23:31 ` Francois Romieu
2005-02-05 19:38 ` Stelian Pop
2005-02-05 23:38 ` Larry McVoy
2005-02-08 15:43 ` Stelian Pop
2005-02-08 15:58 ` Larry McVoy
2005-02-08 17:17 ` Roman Zippel
2005-02-08 18:16 ` Larry McVoy
2005-02-08 18:52 ` Roman Zippel
2005-02-09 0:07 ` Theodore Ts'o
2005-02-09 2:05 ` Roman Zippel
2005-02-09 2:24 ` Jon Smirl
2005-02-09 2:35 ` Roman Zippel
2005-02-09 2:39 ` Larry McVoy
2005-02-09 2:47 ` Roman Zippel
2005-02-09 3:40 ` Larry McVoy
[not found] ` <Pine.LNX.4.61.0502091128070.7836@localhost.localdomain>
2005-02-09 17:38 ` Jon Smirl
2005-02-09 18:24 ` Nicolas Pitre
2005-02-09 18:48 ` Jon Smirl
2005-02-09 23:31 ` Roman Zippel
2005-02-09 23:52 ` Jon Smirl
2005-02-09 23:22 ` Roman Zippel
2005-02-10 0:13 ` Larry McVoy
2005-02-10 19:34 ` d.c
2005-02-11 8:40 ` Stelian Pop
2005-02-09 2:40 ` Jon Smirl
2005-02-09 2:57 ` Roman Zippel
2005-02-09 3:03 ` Jon Smirl
2005-02-09 5:48 ` Gene Heskett
2005-02-09 9:05 ` Miles Bader
2005-02-09 7:06 ` Alexandre Oliva
2005-02-09 14:48 ` d.c
2005-02-09 15:51 ` Larry McVoy
2005-02-09 17:30 ` Nicolas Pitre
2005-02-09 17:44 ` Valdis.Kletnieks
2005-02-10 5:44 ` Horst von Brand
2005-02-10 9:36 ` Alexandre Oliva
2005-02-10 21:17 ` Larry McVoy
2005-02-11 9:02 ` Stelian Pop
2005-02-11 15:30 ` Alexandre Oliva
2005-02-11 15:48 ` Larry McVoy
2005-02-11 16:18 ` Larry McVoy
2005-02-11 16:54 ` Alexandre Oliva
2005-02-11 16:13 ` Jon Smirl
2005-02-11 17:22 ` Alexandre Oliva
2005-02-11 20:00 ` Larry McVoy
[not found] ` <20050210222403.GA5920@thunk.org>
[not found] ` <or650z6syt.fsf@livre.redhat.lsd.ic.unicamp.br>
2005-02-11 15:53 ` Larry McVoy
2005-02-11 17:24 ` Alexandre Oliva
2005-02-10 5:47 ` James Bruce
2005-02-06 16:40 ` Roman Zippel
2005-02-06 17:39 ` Larry McVoy
2005-02-07 1:45 ` Roman Zippel
2005-02-07 2:10 ` Larry McVoy
2005-02-08 14:57 ` Roman Zippel
2005-02-08 15:19 ` Larry McVoy
2005-02-08 15:24 ` Stelian Pop
2005-02-08 15:47 ` Larry McVoy
2005-02-08 15:36 ` Catalin Marinas
2005-02-08 15:58 ` Jon Smirl
2005-02-08 16:15 ` Roman Zippel
2005-02-08 17:17 ` Valdis.Kletnieks
2005-02-08 17:23 ` Roman Zippel
2005-02-08 17:01 ` Larry McVoy
2005-02-07 2:16 ` Al Viro
2005-02-04 10:18 ` Michael S. Tsirkin
2005-02-04 10:59 ` Stelian Pop
2005-02-04 11:08 ` Michael S. Tsirkin
2005-02-04 11:20 ` Stelian Pop
-- strict thread matches above, loose matches on Subject: below --
2005-02-09 18:46 Larry McVoy
2005-02-09 20:13 ` Nicolas Pitre
2005-02-09 23:53 ` Larry McVoy
2005-02-10 0:14 ` Roman Zippel
2005-02-10 0:50 ` Larry McVoy
2005-02-10 9:52 ` Roman Zippel
2005-02-10 10:11 ` linux
2005-02-10 6:08 ` James Bruce
2005-02-10 15:14 ` Stelian Pop
2005-02-10 16:42 Steve Lee
2005-02-10 19:23 ` Vojtech Pavlik
2005-02-10 19:50 ` Dmitry Torokhov
2005-02-11 18:56 none given
2005-02-11 19:50 ` Larry McVoy
[not found] <fa.hd724f5.h36q2j@ifi.uio.no>
2011-08-18 19:08 ` lucasrangit
2011-08-18 19:22 ` Randy Dunlap
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050204160631.GB26748@bitmover.com \
--to=lm@bitmover.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=stelian@popies.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox