activating a view doesn't delete excluded files

[Eduardo de Oliveira Padoan]

Testing the new Filtered Views feature on bzr.dev r4030:

(~/dev/junk/testbranch) edcrypt@edcrypt-laptop$ bzr.dev ls
somedir/
somedir/somefile1.txt
somedir/somefile2.txt
somedir/subdir/
somedir/subdir/somefile1.rst
somedir/subdir/somefile3.txt
somefile4.XXX
(~/dev/junk/testbranch) edcrypt@edcrypt-laptop$ bzr.dev view somedir
Using 'my' view: somedir
(~/dev/junk/testbranch) edcrypt@edcrypt-laptop$ bzr.dev ls
somedir/
somedir/somefile1.txt
somedir/somefile2.txt
somedir/subdir/
somedir/subdir/somefile1.rst
somedir/subdir/somefile3.txt
somefile4.XXX
(~/dev/junk/testbranch) edcrypt@edcrypt-laptop$ bzr info -v
Standalone tree (format: development-wt5-rich-root)
Location:
  branch root: .

Related branches:
  parent branch: .

Format:
       control: Meta directory format 1
  working tree: Working tree format 5
        branch: Branch format 7
    repository: Packs 6 rich-root (uses btree indexes, requires bzr 1.9)

In the working tree:
         7 unchanged
         0 modified
         0 added
         0 removed
         0 renamed
         0 unknown
         0 ignored
         2 versioned subdirectories

Branch history:
         2 revisions
         1 committer
         5 days old
   first revision: Mon 2009-02-16 19:36:44 -0300
  latest revision: Mon 2009-02-16 20:39:51 -0300

Repository:
         2 revisions

[Ian Clatworthy (ian-clatworthy)]

Eduardo de Oliveira Padoan wrote:
> Public bug reported:
>
> Testing the new Filtered Views feature on bzr.dev r4030:
>
> (~/dev/junk/testbranch) edcrypt@edcrypt-laptop$ bzr.dev ls
> somedir/
> somedir/somefile1.txt
> somedir/somefile2.txt
> somedir/subdir/
> somedir/subdir/somefile1.rst
> somedir/subdir/somefile3.txt
> somefile4.XXX
> (~/dev/junk/testbranch) edcrypt@edcrypt-laptop$ bzr.dev view somedir
> Using 'my' view: somedir
> (~/dev/junk/testbranch) edcrypt@edcrypt-laptop$ bzr.dev ls
> somedir/
> somedir/somefile1.txt
> somedir/somefile2.txt
> somedir/subdir/
> somedir/subdir/somefile1.rst
> somedir/subdir/somefile3.txt
> somefile4.XXX

That's for the fast feedback. The feature only landed an hour or so
before this bug report. Awesome!

By design, filtered views do not delete other files in the working tree.
A bit like a database view, they simply provide a lens on to the
information. I am planning to implement a feature closer to what you're
expecting - partial trees. See http://bazaar-vcs.org/FilteredView if you
haven't already. Technically, the latter is harder than it sounds. For
example, merge expects *all* the files to be in the tree (and merge
needs to remain a tree-wide operation, even if a view is active and you
only see the bits you interesting in via status, diff and commit).

Having said the above, I certainly think that there are some commands
where the filtered view ought to apply and it doesn't yet. ls is one
example - I hadn't thought of that one. I think they ought to apply for
shelve as well. They *might* - I'm yet to test it - but there certainly
isn't a unit test for shelve yet and there needs to be. In the case of
shelve, I don't think it existed in the core when I first wrote the
filtered views code. I don't have any excuse for ls though. :-)

I also feel some commands should explicitly ignore the view, though
perhaps they should make it clearer they are doing so. log and info
are examples of commands in this category.

Ian C.

[Eduardo de Oliveira Padoan (eopadoan)]

> That's for the fast feedback. The feature only landed an hour or so
> before this bug report. Awesome!

Its bloody carnival, and I wasn't inspired to to get out the house, so...
Also this is a very cool feature, I really want to see it shipped.

> By design, filtered views do not delete other files in the working tree.
> A bit like a database view, they simply provide a lens on to the
> information. I am planning to implement a feature closer to what you're
> expecting - partial trees. See http://bazaar-vcs.org/FilteredView if you
> haven't already. Technically, the latter is harder than it sounds. For
> example, merge expects *all* the files to be in the tree (and merge
> needs to remain a tree-wide operation, even if a view is active and you
> only see the bits you interesting in via status, diff and commit).

I have read this page once when you proposed the feature only, but I'll take a better look, thanks.

So, If I try to merge, it still needs to get the complete list of files. Ok. But 'bzr help view' (a quite long doc, btw :P) says:

"""
  To disable the current view without deleting it, you can switch to
  the pseudo view called ``off``. This can be useful when you need
  to see the whole tree for an operation or two (e.g. merge) but
  want to switch back to your view after that.
"""

I guess that its because we will want to check 'bzr st' and etc before committing the merge (and so will need the whole list of affected files), or simply because the committing the merge will fail If we aren't viewing the whole tree?

> Having said the above, I certainly think that there are some commands
> where the filtered view ought to apply and it doesn't yet. ls is one
> example - I hadn't thought of that one. I think they ought to apply for
> shelve as well. They *might* - I'm yet to test it - but there certainly
> isn't a unit test for shelve yet and there needs to be. In the case of
> shelve, I don't think it existed in the core when I first wrote the
> filtered views code. I don't have any excuse for ls though. :-)

BTW, I discovered this testing my plugin, bzr-rxrename (not a definitive name :). It uses WT.inventory.get_entries_by_dir().

> I also feel some commands should explicitly ignore the view, though
> perhaps they should make it clearer they are doing so. log and info
> are examples of commands in this category.

[Ian Clatworthy (ian-clatworthy)]

Eduardo de Oliveira Padoan wrote:

> So, If I try to merge, it still needs to get the complete list of files.
> Ok. But 'bzr help view' (a quite long doc, btw :P) says:
>
> """
> To disable the current view without deleting it, you can switch to
> the pseudo view called ``off``. This can be useful when you need
> to see the whole tree for an operation or two (e.g. merge) but
> want to switch back to your view after that.
> """
>
> I guess that its because we will want to check 'bzr st' and etc before
> committing the merge (and so will need the whole list of affected
> files), or simply because the committing the merge will fail If we
> aren't viewing the whole tree?

The commit of the merge has to commit all the changes because Bazaar
doesn't support committing only some files if there's a pending merge.
So even if a view was active and the user only saw changes that impacted
the view, merge must be "normal" (full-tree + all changes committed)
behind the scenes. Right now, I make no attempt to sugar-coat that so

  bzr view --switch off
  (do merge)
  bzr view --switch my

is the recipe needed, assuming the default view name is being used.
I guess I need to make that clearer in the doc.

Ian C.