attn: abentley Re: [BUG] Merging repositories with a directory deleted

Robert Collins robertc at robertcollins.net
Thu Sep 15 09:38:59 BST 2005


On Wed, 2005-09-14 at 17:06 -0400, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Aaron Bentley wrote:
> > What I really need is a comprehensive exception-handling spec.  So far,
> > I've just been handling each case as it bit people, based on vague ideas
> > of 'the right way'.
> 
> So I'm looking at it now, and I can see why I never handled it before:
> Let's say, worst-case scenario, the file doesn't exist in THIS, and some
> of its parent directories are also missing.
> 
> 1. Do I use BASE or OTHER for the path?
> 2. Do I use the exact path from that tree, or do I invent a path by
> iterating up through parents in OTHER/BASE until I find something that
> exists in THIS?
> 3. When I make the directories, do I also add them to the inventory of THIS?
> 4. What do I do if there's something in the way?

Hmm. So I think inventing a path is fine as long as we tell people what
the old path was.. however for its parent to be missing suggests that
the parent's delete *should also have been a conflict* -because its
content (the child paths) were not all gone. This would naturally apply
recursively.

Yes, new dirs should go in the inventory. And for the something in the
way case, the same as a double add of files.

Now, there is an interesting thing here, the last step of baz2bzr
applies a delta to change its starting point into the current head, but
this can fail due to conflicts - is it possible to tell merge 'just do
it' as opposed to 'conflicts can happen' ?

Rob


-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050915/0d517328/attachment.pgp 


More information about the bazaar mailing list