Re: [ANNOUNCE] BK->CVS (real time mirror)

[Daniel Jacobowitz <dan@debian.org>]

On Wed, Mar 12, 2003 at 11:51:20AM -0800, Larry McVoy wrote:
> Well, I agree that they should be able to get at the information in a 
> neutral way.  I guess it was unrealistic, but I was expecting that people
> would go download the CVS tree and poke around and see if it is what they
> wanted.  We could have had a nice technical discussion about what was 
> missing, if anything.  If the discussion had happened, they would have 
> found out that even for the missing deltas we captured the information.
> 
> Here's an example.  Suppose the graph is like
> 
> 	1.1 (torvalds) -> 1.2 (alan) -> 1.3 (sct) -> 1.4 (torvalds) 
> 	             \                             /
> 		      \-> 1.1.1.1 (davej) --------/
> 
> and we picked the straight 1.1 to 1.4 path.  When we created the CVS 1.4
> delta, we knew that it was a merge delta and we needed to capture the 
> data off on the branch.  We already capture the contents, the missing part
> is what davej may have typed in as comments.  We capture that as well, it
> looks like this:
> 
>     revision 1.342
>     date: 2003/03/07 15:39:16;  author: torvalds;  state: Exp;  lines: +7 -1
>     [PATCH] kbuild: Smart notation for non-verbose output
> 
>     2003/03/05 19:50:27-06:00 kai
>     kbuild: Make build stop on vmlinux link error
> 
>     (Logical change 1.8166)
> 
> That particular example is from the top level Makefile, Linus merged
> in Kai's work and we added the "kbuild: Make build stop on vmlinux link
> error" comments from the merged in delta.  If there were more than one
> delta, they get merged as well, so the rlog output is completely accurate.

Larry, this brings up something I was meaning to ask you before this
thread exploded.  What happens to those "logical change" numbers over
time?

My understanding (since you mentioned ~ 3 minute latency on BK pushes,
not five hour latency) was that future changes would go into CVS
incrementally.  As far as I understand the "revision numbers" that BK
uses, they're subject to change.  Based on what trees Linus merges
from, a revision number in his repository may not always have the same
number.  So the comments will become out-of-date and inaccurate.

Or am I wrong about the potential for change within a single
repository?


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer