[Prophesy] General questions

[Rasmus Andersen]

On Sat, May 04, 2002 at 06:59:32PM +0200, Daniel Phillips wrote:
> 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.

I'll have to try this. I think that my current third-hard impressions
are too vague for this.

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

The BK equivalent of two different developers downloading source from
kernel.org would be cloning local repositories from linus', no? Then
it seems like the above reduces to BK interfacing with the outside
(non-BK) world, which is then problematic? Or am I missing something?

AFAIK, the strict 'tree' view of the revision history is due to the
fundamental distributed view of the process here, with all trees
being seens (designwise) as a replicas of a distributed filesystem.

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

I agree on this object view, even though we should call them closures,
in proper LISP terminology :) Warning, this is about it for my LISP
knowledge.

[More object think]

I agree on this. I'll have to think a bit about this in order to
wrap my brain around it.

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

I think objects can contain objects. That way merges can be objects too,
containing the objects merged as its revision history.

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

I dont think so but it is a BS guess. One problem would be later
changes modifying htree code, making extraction of the htree patch
difficult.

Another question is your described effort in managing change sets
for your patches. Could you decribe this a bit so we could see if
we could envision something to make that easier?

Rasmus