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

[Daniel Parks]

On Jul 17, 2007, at 1:56 PM, Aaron Bentley wrote:
> Wow, is mv ever DWIMmy.

Normally I'm not a fan of DWIM, but this is consistent with the  
behavior for files.

Actually, it's more of a matter that there are two types of move  
operations:
  - rename a to b
  - move a into b/

The UNIX mv command and therefore bzr mv have DWIM magic in them  
already. Because of the history there, we can't really avoid the DWIM.

It might be nice to have a flag the explicitly chooses the operation.  
I think people have suggested separate move and rename commands in  
the past (which I think is a bad idea), but a flag might be nice,  
since it's an obviously optional choice. (Whereas if you look at the  
list of commands you're forced to choose between move and rename.)  
Hope that makes sense.

Personally, I think that a flag is a little more work than it's worth.

> Even so, your patch looks reasonable.  The one issue I see is that  
> you're comparing osutils.file_kind to inv.get_file_kind.  
> osutils.file_kind can return 'file', 'directory', or 'symlink', and  
> inv.get_file_kind can also return them.  But inv.get_file_kind can  
> also return 'tree-reference', and your code will not behave  
> properly in this case.

Ah, good to know. I'll take a look at the docs on nested trees and  
update the patch. I don't think there are any mv tests for tree- 
references -- I'll add some.

Thanks,
Daniel