Re: [Gnu-arch-users] Re: cscvs--experimental--1.1 nearing doneness; call for testers

[Tupshin Harper]

Tom Lord wrote:

> Ok, that's what I figured.
>
> I hate to raise the bar but, I'm thinking that a really good mirror of
> linux bkcvs to arch is going to have one of two properties:
>
> a) it's going to be at the granularity of linus commits -- not the 
>   sub-commits that he is summarizing.
>  
A painful compromise. I'm sure that Andrea will scream at that one.

> b) the total granularity is preserved -- but in multiple arch archives
>   and with some patch-log pruning.   The branching structure among
>   the various archives is going to reflect the patch-flow topology of
>   the project.
>  
Not sure how the archives would be rationally broken up. On one extreme, 
you have one monolithic archive, and on the other, you have one archive 
per person who has ever had a change incorporated into the kernel. Are 
you thinking along those latter lines, or is there some *sane* middle 
ground?

>    > So if Joe Schmo starts with (for example) Linus' kernel  2.4.19, writes 
>    > a new scheduler (for the 9 billionth time) and iteratively improves it 
>    > over the course of a couple months until Linus decides it's ready to go 
>    > into his tree, then all of the changesets that Mr. Schmo created along 
>    > the way are committed to Linus' tree. If Joe incorporated changes from 
>    > other people, than it gets even more complex. There is, effectively, a 
>    > directed , single rooted, but multi-parented graph of changesets 
>    > incorporating every bit of history of the changes that Linus ultimately 
>    > commits.
>
> Yezzz.   Well, in arch, this might work out a bit differently in
> practice.
>  
Any reasons other than performance?

>   > The CVS (implicitly)and SVN (explicitly) versions of the bitkeeper trees 
>    > have a much different level of granularity. They only have 1 
>    > patch/diff/changeset/whathaveyou per Linus' commit. This is obviously a 
>    > much simpler structure to import, but it is necessarily very lossy.
>
> Not obviously lossy in important ways but, there is a slow modem
> between me and the source material in this discussion, and a slow
> machine and tiny disk on this end -- so it's hard for me to
> investigate at this point.
>  
I'm willing to do some investigation if it would help.

Regarding lossiness, it seems pretty clear. Compare what's in SVN to 
what's in BK. Look at the svn 2.6 tree, specifically patch 13272.
Obtainable by two lightweight operations:
svn diff -r 13271:13272 svn://svn.kernel.org/linux-2.6/trunk to get the 
diff itself
svn log 13272 svn://svn.kernel.org/linux-2.6/trunk to get the comments.

It consists of 3 bitkeeper changesets by two different people. So if you 
commit the entire thing as a single undifferentiated patch, you lose:
1) Who wrote which code
2) Which comments went with which code
3) Which changes made some kind of atomic sense at the time that they 
were written.

This seems like an extremely large degradation from what Linus is using 
today.

-Tupshin