bzr mv should handle and report failure better

I agree that bzr should report about already moved things until it encounters error. But I don't think bzr should continue to work if some error encountered. So I'd like to fix reporting problem rather than made all moves independent.

To fix problem with reporting I think we should extent arguments of tree.move() method with one optional argument `report`. This argument could be a list object to accumulate finished moves info. So if error will be raised command mv still will be able to get report and show it in finally block. Something like this:

# move into existing directory
report = []
try:
     tree.move(rel_names[:-1], rel_names[-1], after=after, report=report)
finally:
    for pair in report:
        self.outf.write("%s => %s\n" % pair)

IMO it will be simplier to implementing and testing. But will require additional tests in bzrlib/tests/workingtree_implementations/

Spencer, do you want to rework your patch in this way? If not I'll do it.

Note: There is additional discussion on this issue on the mailing list.

My initial reaction here was to agree with Alexander. My concern was consistency: it's nice to do things as comprehensively as possible, but if that means being inconsistent with other bzr commands, then the patch would be a local optimisation at the expense of the overall UI. Digging deeper though, I think Spencer's approach is sound and indeed consistent with other parts of Bazaar ...

For example, if I have a branch with 3 files called a, b and c, and run 'bzr remove --keep a d c", I get the following output:

  d is not versioned.
  removed c
  removed a

So remove works as Spencer is suggesting. I'd like to say 'add' works the same way but it arguably has a bug. Consider:

  $ touch a b c
  $ bzr add a d c
  added a
  bzr: ERROR: No such file: u'/home/ian/tmp/play/testmulti/d'
  $ bzr st
  unknown:
    a
    b
    c

So add is reporting partial success when if fact nothing happened. I'll raise a bug for that.

The original patch was

http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C64ab70ac0802041811u61752e66l3a04f025336390ae%40mail.gmail.com%3E

To find the thread, look for 177809 in the list archives from early 2008.

The patch foundered over the location of the code and [less so] the manner of the approach.

Just noting this here to help folk coming to work on it.

Personally, I'd be inclined to change bzr to plan the rename, create a tree transform of it, and apply it. That would allow tree transforms rollback etc logic to be used and perhaps shrink some duplicate code.