the inventory must be updated as merge proceeds, not at the end

[Denys Duchier]

Aaron Bentley <aaron.bentley at utoronto.ca> writes:

> I see the surgical operations as something that is only necessary for
> performing tree transforms on a filesystem (or possibly the inventory).
>  I don't think they're necessary to calculate a merge.

That's true, but you then still have to apply the computed transform
and that's when you need to come up with an appropriate sequence of
surgical operations.

> If you have a tree transform object, and you want to create a file
> before its parent exists, you can do that.  You can have two files with
> the same name, or same file id, too.

You propose a very elegant abstraction, but I don't believe that that
level of generality is truly advantageous in practice, or more
precisely that it's worth the trouble.  It feels to me like you have
just made the problem harder elsewhere, namely in your proposed
abstraction.  We seem to be trading off "une usine à gaz" for very
little added convenience.

> Because there are fewer invariants, I don't see the need for the concept
> of 'limbo' in the tree transform API, though it would certainly be used
> for applying the transform.

You see!  You want to introduce a fairly complex abstraction over the
limbo idea (an idea which, in some form or other, has been there from
the start and that we understand fairly well because it is
straightforward).  Is this really going to simplify the bzr code?  Is
it going to simplify the merge code itself: maybe we will be able to
proceed in 1 pass instead of 2.  And this minor simplification comes
at what cost?: an entirely new bunch of code to implement tree
transforms - and some FS code that used to be executed during cs entry
application will now migrate into tree transforms (but it is not going
away).  I hope you understand why I remain unconvinced of the
practical benefits.

My "shadow FS" proposal is considerably simpler and has wider
applicability (e.g. running simulations that are not about computing
tree transforms but may nonetheless side-effect the file system).
Furthermore, it's a device that I have used many times in practical
applications; so (to me) it has proven its worth.

>> I also have the nagging feeling that what you are thinking of is more
>> specifically designed for the working tree proper and may not apply
>> directly to providing similar facilities for files under .bzr, but I
>> hope I am wrong about that.
>
> Tree transforms should happen at a level above the filesystem level,
> because what's on the disk may not match the WorkingTree.  Specifically,
> we want to support CVS-style keywords.
> http://bazaar.canonical.com/KeywordExpansion

??? err... I don't see how that's an answer to the quoted paragraph,
nor how it relates to the present discussion: would it not make sense
for KeywordExpansion to happen during computation of a "contents"
merge?  In other words, it should already be done in the changeset -
it is, after all, a modification of "contents".

Cheers,

--Denys