[MERGE] Bug #107967: fix bzr mv --after on a directory

[Daniel Parks]

On Jul 15, 2007, at 2:33 AM, James Westby wrote:
> The bug is talking about bzr mv --after, whereas your patch does not
> seem to consider the --after flag. The bug states that the correct  
> thing
> is done in when there is no need for --after, (the source doesn't
> exist).

Actually, bzr mv would fail with and without --after. In this  
particular case, --after doesn't change the behavior.

For example:

   bzr mkdir a
   mv a b
   bzr mv a b

This is equivalent to doing the same thing with files. Previously,  
bzr mv would error, now it succeeds to rename a to b in the inventory  
(working tree?).

If we add --after to the last command, nothing changes.

You mentioned a second case:

>   mkdir a
>   bzr add a
>   mv a b
>   mkdir a
>   bzr mv a b

John mentioned in a comment on the bug that he was OK with failing in  
this case. --after doesn't make a difference here, either, because  
you could mean "bzr mv a b/a" or "bzr rename a b". I hope that makes  
sense.

I've attached a new bundle with a few tests for these cases that you  
mentioned (including the one with the file). If you have other cases  
you're interested in, let me know.

> I believe that
>
>   if inv.path2id(rel_names[1]) is not None:
>
> is preferred.

Thanks, fixed.

Is there a chance in the current code that the id evaluates to false,  
or is this a matter of being clean and correct? I found this  
elsewhere in the code, so I'm wondering if it's important to fix.

Thanks for the feedback!

Daniel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-mv-107967-2.patch
Type: application/octet-stream
Size: 20622 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070716/537055fa/attachment-0001.obj