Re: BK kernel workflow

Roman Zippel
2004-10-28T01:55:33Z

Hi,

On Wed, 27 Oct 2004, Larry McVoy wrote:

> 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.

Actually the Commit numbers are far more interesting and here you have
difference of 56% you haven't explained.
A large number of CVS commits are really also single BK commits (let's say
30%, I have to leave the verification to you, but I don't think I'm that
far of), that would leave 70% of BK commits merged into 32% of CVS
commits. These 70% can't be extracted anymore as a single logical change
from CVS.
The only reason this number isn't worse is that the kernel development is
still quite serial, e.g. most of the patches sent by Andrew show up as a
single commit, but the more people use bk the worse these numbers get.

> That's pretty darned good IMO.

I can play with numbers too...

> 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.

You're only telling half of the story and I'm afraid you'll get away with
it, because most people don't really know the topic that well and I can't
blame them.

bye, Roman