[MERGE] 1.14 formats

[Robert Collins]

On Sat, 2009-03-28 at 15:33 +1000, Ian Clatworthy wrote:
> 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

In  other systems a staging area is one that can have a different
content - such as the git index. I'd be cautious about calling it a
staging area because of this.

> > 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.

I'm pro doing this.

> > 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.

Clearly format bumps cannot manage interactions with plugins, and I
wasn't suggesting they be used for that. That would be horrid :).

>  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.

Well, I'm not worried about plugins here, I'm asking if there is the
opportunity for people to end up with mismatched trees if 1.15 adds the
indirection stuff for the config you're planning on doing, and they are
using 1.14 and 1.15 [for instance a shared tree on a LAN would be
subject to that].

I'm also keen to see eol land and be supported, but its worth a little
consideration to make sure we're ready. 

-Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090328/4f40713c/attachment.pgp