Storage requirements of tree transforms
Martin Pool
mbp at sourcefrog.net
Mon Jan 23 03:03:12 GMT 2006
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
More information about the bazaar
mailing list