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

[James Westby]

On (16/07/07 12:52), Daniel Parks wrote:
> 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.

Thanks for the clarification. It seems like you have considered the
change well.

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

Thanks, the tests would now catch some interesting failures. There are
probably a couple of other permutations that could be tested, but that's
not vital.

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

It is mentioned in PEP-8. bzr follows that where it makes sense to do
so. I very much doubt you would get an id that evaluated to False, but
it does make the intent of the test clearer.

One thing that surprised me was the error messages that some operations
gave, stating that the destination wasn't versioned, particularly when
sub1 and sub2 were both unversioned. However with automatic detection of
already moved files the user's intent is a little murky.

Your mail client sends a message that is different to those sent by
others it seems, as the attachment is not included in my reply to you. I
guess this is because it's MIME type is octet-stream, but I'm not too
sure. It's not a big issue as your patch is there and still works, and I
don't know if this affects other people.

Thanks,

James

-- 
  James Westby   --    GPG Key ID: B577FE13    --     http://jameswestby.net/
  seccure key - (3+)k7|M*edCX/.A:n*N!>|&7U.L#9E)Tu)T0>AM - secp256r1/nistp256