"bzr update FILENAME" modifies more than just FILENAME

From the bazaar mailing list:

"""
Hi folks!

The subject is little provocative to inspire
you to read it but it did mix up my uncommitted
changes. Anyways I've used bzr for at least
a year now and love it.

I manage quite a big project with bzr and
was doing couple of days of refactoring
of many parts of the program at once not
committing many of the untested changes yet.
(I want them at least to compile before
committing).

Yesterday during compile testing the changed
parts I wanted to revert one file in some
library and ran command:
  bzr update -r1234 myfilename.c

Well this was a big mistake by my side
because what I meant to do was:
  bzr revert -r1234 myfilename.c

The update-command reverted many uncommitted
changes around the project and mixed
them with older version. Now my repository
is full of conflicts and code files with
older and newer changes mixed up in them
and .THIS, .BASE and .OTHER files.

I have now a serious work to manually figure
out which files have moved to where (they were
also moved around during the refactoring) and
compare files and do the merging manually.

Too bad there is no undo for "update" (or
any other command) in bazaar.

Of course this is my mistake completely not
committing every part of the refactoring
before testing to compile it.

I'd like to request a feature for bzr to test
for invalid command line arguments (like the
filename for "bzr update") and not execute
the command in such case. Bzr update does
take optional directory as an argument but
I gave it filename and testing for it being
file and the cancel update would have prevented
this from happening to me or anyone else.
"""

I agree that this is surprising and probably unwanted behaviour. If I do "bzr update README", I don't expect other parts of the tree to be modified. (Whether bzr should support that is a separate question, but I think it should either fail or just update README, not silently choose to modify the whole tree.)

In terms of code, the reason is that cmd_update uses WorkingTree.open_containing on its DIR parameter, rather than just open. Is this intentional? I notice none of the blackbox tests appear to depend on this behaviour.