Storage requirements of tree transforms

[Martin Pool]

On 17 Jan 2006, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> Martin Pool wrote:
> ~  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.

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.

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

Actually probably .bzr.limbo.tmp would be better :-)

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

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.

-- 
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060123/a78c2c85/attachment.pgp