Storage requirements of tree transforms

[Aaron Bentley]

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

Martin Pool wrote:
| I think relaxing requirement #1 is completely fine.

Cool.

~  I think having
| something there is less important than how it behaves if e.g. the
| operation is interrupted.  I don't think all the updates need to be
| journalled, but it should at least get cleaned up by some operation like
| revert or unlock.

Do you mean commandline operations here?  The cleanup is currently being
done by TreeTransform.finalize, but this makes me somewhat
uncomfortable, because it can delete uncommitted source files.

On the other hand, I expect TreeTransform.apply to be very reliable,
because none of the operations it does are very complicated.  All the
complicated stuff is done up front, before we invoke apply, and nothing
dangerous is done until we invoke apply.

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

|>But there are more complex examples in which it is not apparent that two
|>pathnames refer to the same file.  For example, when a tree is visible
|>on the local FS and also on nfs.
|
|
| How would you handle that?

By calculating the text merge results before making any changes to the
working tree.

|>The transform application uses a temp directory used to hold files
|>undergoing moves/renames, called ".bzr/limbo".

| Perhaps call it limbo.tmp to indicate it can be discarded?

Okay.

| So if I understand properly, creation of the text of the merged file is
| delayed until the tree transform is applied.

The actual file is created ahead of time, and it is moved into place
when the tree transform is applied.

| That sounds good.  (I
| wonder if it should be an object interface rather than an iterator but I
| can't think of anything else that would go in that interface.)

Hey, iterators are objects, too :-)  Seriously, using iterators makes it
very easy to satisfy the interface, and I think that's an advantage, but
I'd be open to suggestions.

To take another extreme, we could accept a path to a file on the same
filesystem, and just rename it into limbo.

| But
| perhaps you won't know whether there are textual conflicts until the
| text merge is attempted.  It would seem a shame to run the text merge
| twice.

I think my example would have been clearer if I'd done it like this:

~    ...
~    merged = Merge3Iter(this, base, other)
~    tree_transform.create_file(merged, trans_id)
~    if merged.conflicts:
~        tree_transform.new_file(name+".THIS", parent, this,
~                                executable=executable)
~    ...
~    tree_transform.apply()
~    ...

That is, we find out whether there were textual conflicts long before we
apply the transform.

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

iD8DBQFDza4u0F+nu1YWqI0RAikfAJ9lBeiAN8z8BBsFw+izVPK5qKv9JQCfXcHG
Wz3DtFu+ClCl+zTdem6jrqE=
=JpU1
-----END PGP SIGNATURE-----