[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Tupshin Harper
Subject: Re: [Gnu-arch-users] Re: cscvs--experimental--1.1 nearing doneness; call for testers
Date: Tue, 30 Sep 2003 17:56:09 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20030924

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
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:// to get the diff itself
svn log 13272 svn:// 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]