[Prophesy] General questions

[Daniel Phillips]

On Saturday 04 May 2002 16:49, Rasmus Andersen wrote:
> On Sat, May 04, 2002 at 04:37:45PM +0200, Daniel Phillips wrote:
> > > Or are you talking about carrying a selected patch set forward across 
> > > multiple tree versions?
> > 
> > The second, and carrying multiple, possibly conflicting patches forward.
> > Logically, this is quite difficult, but in practice we do it all the time.
> > So right now I'm casting around for ways of looking at the problem.
> 
> (I'm spelling this out in order to be sure I get your meaning.)
> So we are talking about the situation where you have three trees,
> all based on a linus one, called 'Daniel's pagethingies', 'rmap
> refinements' and 'aa cleanup'. All three touch mm/page stuff
> heavily and the rmap and aa ones are locally refined by you.
> 
> When Linus updates his tree, you would like to be able to update
> the base tree and have all three local ones updated as well? And
> does BK not do this for you? (Apparently not, but I fail to see
> why not.)

I don't know exactly what happens when you pull from Linus's tree and you 
have incompatible changes in yours.  Please feel free to educate me here, as 
I am not an experienced BitKeeper user.

A major feature of the BitKeeper model that I don't like is the tree model.  
In fact, independent developers don't maintain their trees according to a 
strict heirarchy descending from a common parent.  It's more like a general
net, with developers exchanging bits and pieces with each other in an 
arbitrary graph.  Another way of looking at this is, two different developers 
should be able to download a Linux tarball from kernel.org, each make their 
own changes, then later decide they want to exchange certain changes with 
each other.  With Bitkeeper you'd have to mess around to make that happen - 
on or the other of the developers would have to clone the repository of the 
other and drop back to the patch way of doing things, to manually import 
their changes.  This is BS, we want such exchanges to be entirely natural.

Now, what I'm thinking about here has something to do with the traditional
LISP distinction between EQUAL and EQ, the latter being true when we 
establish that two things really are the *same* object, and don't just have
the same values.  In the LISP case, EQ basically means the addresses of the
objects are the same.  So we want our source tree to be made up of objects,
and each object will have an 'address', which I will call an 'id', which is
perhaps derived from the developer's email address, the date the source tree
first came under management, and an object sequence number (the latter
generated by a counter kept in the root of the source tree).  Objects have 
generations, each generation being a delta.  A 'default' object holds all 
thes ource in the tree that is not included in any other object.  Any state 
of the source tree can therefore be represented as a set of (object, 
generation) tuples.

When two developers wish to match up their trees and exchange object deltas 
(aka patch set, aka change set) in a precise way, the first thing we want to 
do is establish a correspondence between objects in the two trees.  This will 
be a list of tuples of the form (id, id), which establishes that the 
respective objects are EQ.

There are a variety of strategies we could use to build the correspondence.  
We don't have to stick to just one strategy or require it to be entirely 
automatic.  For example, we could consult an already-under-management version 
of our source tree, and import all the object IDs from it that correspond to 
objects that are found to be exactly EQUAL.  We can also do the equality 
tests, somewhat less efficiently (because we also have to partition the 
source into objects) between our two trees.  Or we can simply interpret each 
file as one object, for the purpose of building the correspondence, though we 
would still want to respect the way that the owners of the two trees have 
already partitioned their source into objects.

Next question: what is an object?  Can objects contain objects?  I would like 
an 'change' to be an object, that is, I would like to be able to see how a 
patch evolves, just as we can see how the underlying source evolves as well.

Bitkeeper question: once we apply a changeset to a source base, does the 
Bitkeeper database continue to maintain the identity of the changset as we 
carry the source base through subsequent reversions?  I.e., will Bitkeeper 
let us talk about the 'htree' patch, and let the thing evolve along with the 
source, so that we could pull out the 2.4.17 version of htree, or the 2.4.18 
version, etc?

-- 
Daniel