From: Larry McVoy <lm@bitmover.com>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: Larry McVoy <lm@bitmover.com>, Linus Torvalds <torvalds@osdl.org>,
Andrea Arcangeli <andrea@novell.com>,
Joe Perches <joe@perches.com>,
Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>,
Jeff Garzik <jgarzik@pobox.com>,
Linux Kernel <linux-kernel@vger.kernel.org>,
akpm@osdl.org
Subject: Re: BK kernel workflow
Date: Wed, 27 Oct 2004 17:54:12 -0700 [thread overview]
Message-ID: <20041028005412.GA8065@work.bitmover.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0410272214580.877@scrub.home>
On Wed, Oct 27, 2004 at 10:58:03PM +0200, Roman Zippel wrote:
> Allow me to translate that what this means, so everyone clearly knows
> what's going on here:
> The complete development history of the Linux kernel is now effectly
> locked into the bk format, you can get a summary of it, but that's it.
That's not even close to being the case.
100% of the information is available on bkbits.net, diffs, comments,
everything, all of which you can get at with a wget in a form that
is perfect for import into another system.
100% of the data, diffs, comments, everything, is available in a BK2CVS
exported CVS tree. The comparison of the metadata is as follows:
System File deltas Commits
BK 203,999 53,274 (1)
CVS 195,689 23,429 (2)
In other words, the files which contain the data have 96% of the same
information as the BK files, at the same boundaries, the same patches can
be generated, etc. In 4% of the cases you are looking at a patch which
was two commits in BK but one commit in CVS. In 4% of the cases only.
96% of the time you'd get the same patch from each system.
Every commit in CVS matches up to a commit in BK, so every commit in CVS
represents a point in the BK history where you get identical output from
BK and CVS.
That's pretty darned good IMO. You could pick up with those CVS files
and move forward and you've lost no data, no history, and only a tiny
amount of patch boundary history.
What you have lost is some metadata which doesn't translate into CVS and
doesn't translate into Arch, so that's pointless. And as Andrea said,
Arch can't handle more than 5,000 changesets, and the history exported
is almost 5 times that.
Maybe you weren't aware that that is the situation so you were complaining
about something that wasn't true. Now that you are aware that you are
getting all of the data, all of the comments, in a form which is 96%
of the way to being identical to BK you will no longer have a complaint.
Regardless of what you believe, Roman, I think that anyone can see that
the statement that the development history of Linux kernel is locked
into the BK format is not true. I can't believe anyone could look at
the data and come to your conclusion.
--lm
(1) To reproduce these numbers, get a BK 2.5 tree and do this:
CSETS=`bk prs -hnd:I: ChangeSet | wc -l`
BOTH=`bk -r prs -hnd:I: | wc -l`
DELTAS=`expr $BOTH - $CSETS`
(2) To reproduce these numbers, get a BK2CVS 2.5 tree and do this:
DELTAS=`find . -name '*,v' | grep -v ChangeSet,v | xargs egrep '^head[[:space:]]+1\.[0-9]+;|^next[[:space:]]+1\.[0-9]+;' | wc -l`
Similarly for the ChangeSet,v file to get csets.
next prev parent reply other threads:[~2004-10-28 0:59 UTC|newest]
Thread overview: 161+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <41752E53.8060103@pobox.com>
[not found] ` <20041019153126.GG18939@work.bitmover.com>
2004-10-19 16:06 ` BK kernel workflow Jeff Garzik
2004-10-19 21:33 ` Paolo Ciarrocchi
2004-10-19 21:38 ` Jeff Garzik
2004-10-19 21:54 ` Paolo Ciarrocchi
2004-10-19 22:11 ` Linus Torvalds
2004-10-20 7:35 ` Paolo Ciarrocchi
2004-10-23 16:12 ` Larry McVoy
2004-10-24 10:24 ` Paolo Ciarrocchi
2004-10-24 14:44 ` Larry McVoy
2004-10-24 16:44 ` Paolo Ciarrocchi
2004-10-24 23:32 ` Larry McVoy
2004-10-25 11:33 ` Matthias Urlichs
2004-10-25 11:46 ` Andrea Arcangeli
2004-10-25 12:29 ` Joe Perches
2004-10-25 13:39 ` Andrea Arcangeli
2004-10-25 15:14 ` Linus Torvalds
2004-10-25 15:43 ` Andrea Arcangeli
2004-10-25 16:10 ` Linus Torvalds
2004-10-25 17:22 ` Andrea Arcangeli
2004-10-25 20:04 ` Jeff Garzik
2004-10-26 2:19 ` Miles Bader
2004-10-25 16:20 ` Larry McVoy
2004-10-25 16:47 ` Andrea Arcangeli
2004-10-25 17:12 ` Larry McVoy
2004-10-25 17:34 ` Andrea Arcangeli
2004-10-25 17:18 ` Linus Torvalds
2004-10-25 17:37 ` Andrea Arcangeli
2004-10-26 0:06 ` Roman Zippel
2004-10-26 0:51 ` Linus Torvalds
2004-10-26 2:21 ` Miles Bader
2004-10-27 2:05 ` Roman Zippel
2004-10-27 3:00 ` Linus Torvalds
2004-10-27 4:18 ` Larry McVoy
2004-10-27 16:45 ` Matthias Urlichs
2004-10-27 18:12 ` Buddy Lucas
2004-10-27 20:56 ` Roman Zippel
2004-10-27 21:20 ` Linus Torvalds
2004-10-28 1:14 ` Roman Zippel
2004-10-28 1:34 ` Linus Torvalds
2004-10-27 21:45 ` Alan Cox
2004-10-31 19:50 ` Pavel Machek
2004-10-28 9:20 ` James Bruce
2004-10-28 11:39 ` Geert Uytterhoeven
2004-10-28 13:53 ` Larry McVoy
2004-10-28 14:06 ` Xavier Bestel
2004-10-28 15:10 ` Larry McVoy
2004-10-28 19:20 ` Alan Cox
2004-10-28 19:25 ` David Schwartz
2004-10-28 19:38 ` Kevin P. Fleming
2004-10-28 19:22 ` Alan Cox
2004-10-28 23:22 ` David Schwartz
2004-10-28 23:59 ` David S. Miller
2004-10-29 0:25 ` David Schwartz
2004-10-29 14:31 ` Scott Lockwood
2004-10-29 14:35 ` Xavier Bestel
2004-10-29 17:02 ` The requested ruling (Was: BK kernel workflow) Scott Lockwood
2004-10-30 2:08 ` David Schwartz
2004-10-28 19:59 ` BK kernel workflow Adrian Bunk
2004-10-28 21:35 ` Larry McVoy
2004-10-30 6:51 ` Adrian Bunk
2004-10-30 23:46 ` Larry McVoy
2004-10-30 23:05 ` Alan Cox
2004-10-31 17:47 ` Larry McVoy
2004-10-31 0:28 ` Robert Love
2004-10-31 1:11 ` Adrian Bunk
2004-10-29 17:19 ` Ramón Rey Vicente
2004-10-29 17:36 ` Larry McVoy
2004-10-29 18:06 ` Stephen Frost
2004-10-29 18:20 ` Larry McVoy
2004-10-29 18:08 ` Ramón Rey Vicente
2004-10-29 18:21 ` Larry McVoy
2004-10-29 18:33 ` Scott Lockwood
2004-10-29 18:55 ` Ramón Rey Vicente
2004-10-29 19:14 ` Scott Lockwood
2004-10-30 5:04 ` Kyle Moffett
2004-10-30 20:42 ` Scott Lockwood
2004-10-30 23:35 ` Larry McVoy
2004-10-31 0:20 ` David Schwartz
2004-10-31 2:37 ` Kyle Moffett
2004-10-31 3:34 ` Larry McVoy
2004-10-31 4:01 ` Kyle Moffett
2004-10-31 4:39 ` Larry McVoy
2004-10-31 2:44 ` Kyle Moffett
2004-10-29 19:39 ` Larry McVoy
2004-10-29 20:33 ` Stephen Frost
2004-10-29 23:38 ` Ramón Rey Vicente
2004-10-29 21:11 ` Adrian Bunk
2004-10-30 2:39 ` Larry McVoy
2004-10-30 2:02 ` Al Viro
2004-10-29 19:13 ` Ramón Rey Vicente
[not found] ` <45898.65.208.227.246.1099077395.squirrel@www.lrsehosting.com>
2004-10-29 19:26 ` Ramón Rey Vicente
2004-10-29 23:01 ` Tim Hockin
2004-10-29 20:32 ` Roman Zippel
2004-10-29 22:41 ` Larry McVoy
2004-10-30 11:38 ` Roman Zippel
2004-10-31 21:03 ` Pavel Machek
2004-10-31 21:14 ` Larry McVoy
2004-10-31 21:21 ` Pavel Machek
2004-10-31 21:35 ` Larry McVoy
2004-10-31 21:46 ` Pavel Machek
2004-10-31 23:44 ` Larry McVoy
2004-11-01 3:16 ` Kyle Moffett
2004-11-01 4:57 ` Larry McVoy
2004-11-01 8:39 ` Pavel Machek
2004-10-26 1:01 ` Larry McVoy
2004-10-27 2:30 ` Roman Zippel
2004-10-27 3:54 ` Larry McVoy
2004-10-27 20:58 ` Roman Zippel
2004-10-27 21:16 ` Joe Perches
2004-10-28 0:54 ` Larry McVoy [this message]
2004-10-28 1:49 ` Roman Zippel
2004-10-28 2:35 ` Linus Torvalds
2004-10-28 3:09 ` Larry McVoy
2004-10-28 21:03 ` Roman Zippel
2004-10-28 21:39 ` Eric Mudama
2004-10-28 22:45 ` Larry McVoy
2004-10-28 22:54 ` Roman Zippel
2004-10-29 8:09 ` Manu Abraham
2004-10-29 14:28 ` Scott Lockwood
2004-10-29 15:49 ` Roman Zippel
2004-10-29 16:41 ` David Schwartz
2004-10-29 17:20 ` Valdis.Kletnieks
2004-10-30 0:41 ` David Schwartz
2004-10-29 19:03 ` Chris Friesen
2004-10-29 20:00 ` Ryan Anderson
2004-10-30 0:41 ` David Schwartz
2004-10-31 20:47 ` Pavel Machek
2004-10-31 20:53 ` Larry McVoy
2004-10-31 22:07 ` Sam Ravnborg
2004-10-28 1:05 ` Theodore Ts'o
[not found] ` <mailman.1098759000.989.linux-kernel2news@redhat.com>
2004-10-30 3:55 ` Pete Zaitcev
2004-10-25 19:51 ` Matthias Urlichs
2004-10-26 0:58 ` Andrea Arcangeli
2004-10-26 2:23 ` Miles Bader
2004-10-25 18:18 ` Jon Smirl
2004-10-25 23:01 ` Larry McVoy
2004-10-26 1:28 ` Chris Wedgwood
2004-10-26 2:26 ` Jon Smirl
2004-10-26 6:57 ` Matthias Urlichs
2004-10-26 13:09 ` Giuseppe Bilotta
2004-10-24 17:44 ` Linus Torvalds
2004-10-24 17:48 ` Linus Torvalds
2004-10-24 18:39 ` Michael Buesch
2004-10-26 7:32 ` Matthias Urlichs
2004-10-24 22:33 ` Roman Zippel
2004-10-24 23:04 ` Linus Torvalds
2004-10-19 23:27 ` Greg KH
2004-10-25 13:01 ` Matthias Urlichs
2004-10-25 14:39 ` Paolo Ciarrocchi
2004-10-25 15:48 ` Jeff Garzik
2004-10-25 16:35 ` Matthias Urlichs
2004-10-25 22:05 ` Andrew Morton
2004-10-20 8:31 ` maximilian attems
2004-10-20 9:05 ` Jeff Garzik
2004-10-26 7:38 Chuck Ebbert
2004-10-26 14:23 ` Larry McVoy
2004-10-26 18:16 ` Ryan Anderson
2004-10-26 19:22 ` Larry McVoy
-- strict thread matches above, loose matches on Subject: below --
2004-10-26 15:54 Chuck Ebbert
2004-10-26 20:47 ` Larry McVoy
[not found] <fa.gikv4k0.1tk6shk@ifi.uio.no>
[not found] ` <fa.d7r9f2v.1i6a6on@ifi.uio.no>
2004-10-30 20:54 ` walt
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=20041028005412.GA8065@work.bitmover.com \
--to=lm@bitmover.com \
--cc=akpm@osdl.org \
--cc=andrea@novell.com \
--cc=jgarzik@pobox.com \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paolo.ciarrocchi@gmail.com \
--cc=torvalds@osdl.org \
--cc=zippel@linux-m68k.org \
/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;
as well as URLs for NNTP newsgroup(s).