[MERGE] fix add in view-aware trees

[Ian Clatworthy]

Robert Collins wrote:

> Let me ask again - what will it take to push the stuff that was broken
> down into the tree object so that add wouldn't have broken at all - so
> the bug isn't a UI bug.

I'm not sure at this point.

A large number of API deal in file-ids while views deal with paths so
it's non-trivial to push it down everywhere. It is currently handled
at the *path-processing layer* and that transparently works for 95+%
of current and future commands, add being the notable exception.

Either way, it's well down my list of priorities. Views are not blocking
adoption while getting a brisbane-core format landed, EOL handling and
logging multiple files/directories are.

> As it stands, it sounds like *every* UI will break with views, and thats
> quite undesirable. How can I help us avoid that problem?

I think that's *dramatically* overstating the problem. Only add goes
through the bit of broken code (tree_files_for_add()) and even add
was working for simple cases when I tried to reproduce Mark's bug last
night.

I think we're falling into the trap here of making perfect the enemy
of better. This is a simple "one-line", *obvious* patch. It would have
been found during review if everyone bothered to review the code in the
2 months I had it up for review! We should get this patch approved and
landed IMO and not block it on "redesign filtered views so we don't need
to duplicate a small number of blackbox tests".

I also appreciate the point about GUI tools needing changing to support
views. They will anyway - e.g. a dialog for defining a view and a view
selector widget. Adding a single line call to builtins.tree_files()
is a small fraction of the code they need to duplicate out of the body
of most UI commands. When the GUI guys take on this work, we can tweak
things to assist them then.

Ian C.