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

[Tom Lord]

    > From: Tupshin Harper <address@hidden>

    > You are correct...Linus is not a shell script. 

That's good.  He doesn't look much like one.

    > If he pulls from somebody 
    > elses BK tree, he then commits (atomically) the collection of changesets 
    > that represent the changes that he's incorporating.

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.

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.


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

I think the focus of "linux-in-arch" efforts should _not_ be to mirror
the BK history in all its peculiarities, but rather, to make a useful
framework in which arch-preferring hackers may hack on the kernel.  


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

-t