remove --new deletes parents.

[Dario D'Amico]

Most recent stable windows build:

Bazaar (bzr) 2.5.1
  Python interpreter: C:\Program Files\Bazaar\python26.dll 2.6.6
  Python standard library: C:\Program Files\Bazaar\lib\library.zip
  Platform: Windows-7-6.1.7601-SP1
  bzrlib: C:\Program Files\Bazaar\lib\library.zip\bzrlib
  Bazaar configuration: C:/Users/Dario/AppData/Roaming/bazaar/2.0
  Bazaar log file: C:\Users\Dario\Documents\.bzr.log

There is a branch with a file and a directory. The directory contains two more files.

=== INTERACTION 1 ===
C:\repo\trunk>bzr stat
unknown:
  a/
  z.txt

C:\repo\trunk>bzr add
adding a
adding z.txt
adding a/x.txt
adding a/y.txt

C:\repo\trunk>bzr remove a/x.txt --new
removed a/y.txt (but kept a copy: a/y.txt.~1~)
removed a/x.txt (but kept a copy: a/x.txt.~1~)
removed a (but kept a copy: a.~1~)

It is not clear how the filename is used with the --new option.
Compare the above interaction with the following, in which no
filename is specified and --new is used:

=== INTERACTION 2 ===
C:\repo\trunk>bzr stat
unknown:
  a/
  z.txt

C:\repo\trunk>bzr add
adding a
adding z.txt
adding a/x.txt
adding a/y.txt

C:\repo\trunk>bzr remove --new
removed z.txt (but kept a copy: z.txt.~1~)
removed a/y.txt (but kept a copy: a/y.txt.~1~)
removed a/x.txt (but kept a copy: a/x.txt.~1~)
removed a (but kept a copy: a.~1~)

Finally, consider the case in which the --new option is not
specified, but filename is given:

=== INTERACTION 3 ===
C:\repo\trunk>bzr stat
unknown:
  a/
  z.txt

C:\repo\trunk>bzr add
adding a
adding z.txt
adding a/x.txt
adding a/y.txt

C:\repo\trunk>bzr remove a/x.txt
removed a/x.txt (but kept a copy: a/x.txt.~1~)

I feel like interactions 2 and 3 shows the expected behavior as
described in the manual, while interaction 1 shows an undocumented
(and at least to me counterintuitive) behavior and looks like a bug.

[Dario D'Amico (dario-damico)]

The behavior arises probably from
builtins.py, line 1876 or one of the
invoked modules.

        tree, file_list = WorkingTree.open_containing_paths(file_list)

        if file_list is not None:
            file_list = [f for f in file_list]

        self.add_cleanup(tree.lock_write().unlock)
        # Heuristics should probably all move into tree.remove_smart or
        # some such?
        if new:
            added = tree.changes_from(tree.basis_tree(),
                specific_files=file_list).added
            file_list = sorted([f[0] for f in added], reverse=True)
            if len(file_list) == 0:
                raise errors.BzrCommandError(gettext('No matching files.'))

[Dario D'Amico (dario-damico)]

Note also this comment in workingtree.py, line 293, method open_containing_paths:

            tree = WorkingTree.open_containing(default_directory)[0]
            # XXX: doesn't really belong here, and seems to have the strange
            # side effect of making it return a bunch of files, not the whole
            # tree -- mbp 20100716