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 posted my thoughts as "Transactional Tree Transforms".  I'd be
>>interested to hear what you thought of them.

> Actually, I think we are in agreement.  I am in favour of surgical
> operations being tree operations, but I never said that they should be
> performed directly on the filesystem.

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.

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.

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.

This is good, because the concept of limbo is itself in limbo:
http://www.theglobeandmail.com/servlet/story/RTGAM.20051130.wxlimbo30/BNStory/International/?page=rss&id=RTGAM.20051130.wxlimbo30
:-)

> 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

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

iD8DBQFDtAPt0F+nu1YWqI0RAsMwAJ9WAiIoovXMx8rSoyLtre6FYlYTRACfWoCS
VIGGSLEsNKXBPNGiRB8kRNY=
=S/9m
-----END PGP SIGNATURE-----