Storage requirements of tree transforms

[Aaron Bentley]

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

Martin Pool wrote:
| On 17 Jan 2006, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
|
|>Martin Pool wrote:
| Yes, I did mean by commandline operations.  Perhaps just deleting
| .limbo.tmp would be fine.
|
|
|>| I don't quite understand how that gives condition #2.  Are you talking
|>| about for example renaming directories which contain unversioned files?
|>
|>Well, renames, but of versioned files.
|>
|>Say you do
|>$ bzr get foobranch
|>$ cd foobranch
|>$ echo LALA > README
|>$ bzr mv README FEEDME
|>$ bzr revert
|>
|>If renames are done before content changes, then when we try to do the
|>content change, we cannot find FEEDME in order to use it for the text
|>merge.  I suppose we could actually use the final pathnames and delay
|>text changes until after all changes were applied, but what if
|>filesystem conflicts force us to call it README.moved, instead?
|
|
| OK, I see.
|
| I had in mind that revert would just be putting "overwrite" operations
| into the transform rather than merging with the working copy text.

Yes, the tree transform revert does just overwrite the text with the
revision version.  I was just trying to give an example of a case where
we have BASE or OTHER come from a WorkingTree.

| Right, and the contents of the merge could be written into a file in
| limbo, with the Transform just holding an object pointing to it.  That
| sounds good.

Great.  It's working like that now.

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

iD8DBQFD1GN60F+nu1YWqI0RArzvAJ0QBdpNmuvFFhFZy/LL11sAM+1eIgCeOuor
c8G3QMrcvX4eTOWSYStSgQo=
=prMa
-----END PGP SIGNATURE-----