[MERGE] fix add in view-aware trees

[Ian Clatworthy]

Robert Collins wrote:

> Perhaps views should deal in fileids? That way they would not need
> reconfiguring on 'mv' operations, nor suffer friction at the API layers.

Maybe they will at a much later date. It was seriously considered during
the design, but it introduces as many complications as it solves from memory.
For example, I'd lie to support pattern-based views, e.g. all html files, and
file-ids don't lend themselves to that. I want renaming a file into or
out of a pattern to take it in/out of the view, so tracking mv operations
and keeping the file-id in the view is the wrong thing to do in that case.

> Uhm. AIUI 
> tree = WorkingTree.open('.')
> tree.stuff()
> 
> will not work correctly on a tree that has views.
> 
> Is this right or wrong?
> 
> If I've misunderstood, I'll be very relieved.

It won't check that every access to a file or file-id matches the current
view if that's what you mean by "work correctly". I'm honestly not sure
we want that though. Right now, views are a UI-layer thing, i.e. they
provide implicit selection of a bunch of files. There are not "partial
trees" - a far more advanced feature.

>> 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.
> 
> Even in the common case of work-without-views-in-a-new-format-tree?

No, that should work without any changes. GUIs ought to lookup the
current view though and display just those paths in their UI IMHO.

Ian C.