lkml.org 
[lkml]   [2002]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Problems using new Linux-2.4 bitkeeper repository.
Larry McVoy wrote:

>>Yes it is "altering history"... but... OTOH the user has just told
>>BitKeeper, in no uncertain terms, that he is altering history only to
>>make it more correct.
>>

>*All* of this stuff is trivial if you don't care about passing it on, if
>your repository is a backwater dead end. But that's not the case.
>So you have to decide that you want the events to propagate and if you
>do, then we can do something about it.
>

Re-read my message, assuming I have a clue :) This fits just fine into
the distribute BK system, across any number of pushes and pulls.

I -would- want to pass on the fact that I merged multiple changesets
into a single one...

Think about this example:
* I merge a GNU patch into tree A, creating cset 1.111.
* Marcelo merges the same GNU patch into tree B, creating cset 1.222.
* Time passes. People clone repos off of both trees.
* I 'bk pull' from tree B. Through the merge process, this creates a
brand new "symlink cset", 1.333, which propagates the notion that my
cset 1.111 is a complete copy of 1.222, so we should just read the data
and revision history from 1.222.
* Now, I 'bk push' some changes to Marcelo. This pushes, among other
things, the magic symlink cset 1.333. It does not push 1.111, since
1.333 was the change to the local repo that told it not to. Think of
this like "cset -x" except smarter. "cset -x", as I understand it,
creates a new cset which is essentially the reverse of the specified
cset. Our symlink cset says to BitKeeper (a) not bother with
patch-and-unpatch if both 1.111 and 1.222 are found to be missing
downstream, and (b) if 1.111 but 1.222 are present downstream, to remove
the data associated with 1.111, turning it into a symlink to 1.222.

This fits perfectly well into the BK distributed system, and works
across any number of bk pushes and pulls. Basically, "symlink csets"
would show up in 'bk changes', much like merge csets show up in 'bk
changes' now.

And you are no longer inserting the data N times. The symlink csets
take care of that.

And further, for people scattered all over the world with 1.111 cset,
the 1.333 cset will slowly worm its way across the world, acting like a
janitor and cleaning up BK repositories with duplicated patches :)
Isn't that neat? :)
(assuming that 1.333 cset is propagated out to the world, of course)

>I'm starting to get psyched about this, I think I see a picture that
>works, I need to chew on it for a bit though.
>

whichever works :)

Jeff, who really should sleep now :)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:24    [W:0.154 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site