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

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Denys Duchier wrote:
> 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.

That is true, but I don't understand your point.

>>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 makes it reasonably easy for the tree transform to have multiple
clients.  At the least, we would have

1. build-tree
2. revert
3. merge

It has been made abundantly clear to me that revert and merge should
have significantly different behaviour.  And build-tree would be
amazingly simple.

> It feels to me like you have
> just made the problem harder elsewhere, namely in your proposed
> abstraction.

I could be wrong, of course, but I don't think so.  It looks a bit like
the bzr-changeset plugin, and a bit like the apply_changeset code, but
the actual transform implementation would be simpler, since it would not
 need to handle conflicts.

Conflicts are the big dragon I'm trying to slay.  Conflict resolution
can itself cause conflicts, and that is very hard to handle in the
current model.

Filesystem conflicts can be quite nasty, too, and I'd like to localize
all the conflict checking in one place, in the hope of covering all the
nasty little corner cases properly.

>  We seem to be trading off "une usine à gaz" for very
> little added convenience.

Desole, je ne parle pas le francais courament.

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

I think it would provide a much more accessible api than the changeset
code does.  No callbacks required.  And I think the code itself would
have good separation of concerns, and fewer tricky corner cases.

> And this minor simplification comes
> at what cost?: an entirely new bunch of code to implement tree
> transforms

If you like, I can base it on the work I did on the bzr-changeset
plugin.  Then it will be mostly-old code.

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

This email is the first time I have heard that you were unconvinced of
the practical benefits.

> My "shadow FS" proposal is considerably simpler

The benefits are limited to
1. prediction
2. rollback

right?

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

The relevant phrase is "All access to the working file should be through
the WorkingTree class."

We intended for the merge code to be totally ignorant of any keyword
expansion performed on the file.  All operations would go through a
layer that did expand-on-write, and compress-on-read.  I would expect
that layer to be the WorkingTree.  So yes, it is "designed for the
working tree proper".

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDtCoo0F+nu1YWqI0RAlH1AJ42et50+R9wrpSN8KBNz3c6Spe+XACfelVr
kqtBmavUGxC1XsHh1GixnJI=
=q4Tm
-----END PGP SIGNATURE-----