[MERGE] 1.14 formats

[Ian Clatworthy]

Robert Collins wrote:
> bb:comment
> 
> Three things, the minor one first - are views really a staging area? 

If you want them to be:

  $bzr view foo bar
  View is:foo bar
  (bzr status/diff/revert now operate only on the view)
  $bzr ci -m "blah blah blah"
  Ignoring files outside view. View is: foo bar

> Secondly, AFAICT views are not mature yet; are we ready to commit to
> supporting them as they have been done so far?

I am but others may be not. Views really are simple: they are just
a preselected set of paths passed to tree operations taking a set of
paths. They are essentially a UI-only feature with a small
amount of metadata recording the view definitions. I know you want
something deeper and that will come via a follow-on feature:
partial trees.

I don't think we should block a 1.14 format enabling content filtering
on view maturity. Given --development in 1.14 will be a brisbane-core
format, I'm happy to remove views support from wt5 & add them to wt6,
and bump the brisbane-core format(s) to use wt6.

> More importantly, while I'm happy that filters are robust now and we can
> bring in more facilities, every time we bring in a change that will lead
> to silently doing the wrong thing in mixed version scenarios we need a
> new format bump - and the ongoing changes to configuration for filtering
> certainly meet this AIUI. So I'd say hold off - keep the new tree format
> as beta, and polish it. 

I think you and disagree on this. Format bumps are a crude instrument for
managing content filtering *semantics*, many of which will be buried in
plugins we don't even write ourselves. A safety net is required and it will
come in the form of "requirements" rules. Again, I don't believe that ought
to block picking a set of eol keyword values & supporting them in a
forwardly compatible way for 1.14.

Ian C.