[MERGE] Content filtering (EOL part 2 of 3)

[Robert Collins]

On Sat, 2008-07-19 at 08:50 +1000, Martin Pool wrote:
> On Fri, Jul 18, 2008 at 11:22 PM, Robert Collins
> <robertc at robertcollins.net> wrote:
> >> I don't agree however that this mechanism needs to land in order
> >> for us to land content filtering. To begin with, no plugin using
> >> content filtering will even load on versions of Bazaar without
> >> content filtering in the core - the registration API will be
> >> absent.
> >
> > I agree that that mechanism can likely be deferred. (Not an unqualified
> > agreement - devil in the details). However, something to prevent old
> > bzr's even _looking_ at a content-filtered tree is IMO very important.
> 
> If someone uses an old bzr to look at a tree that has had content
> filtering applied they will just not see the filtering applied when
> they do diff, etc.  This should be reasonably understandable.

I think it will be hugely confusing because there will be *no marker*
that this has happened. We're forcing users to know more about bzr to
debug problems they encounter - and allowing more problems to exist.

> If we wanted watertight protection against people even looking at a
> content-filtered tree we'd need not just a new workingtree format but
> also a new repository format to say that trees in here might have
> filtering information.  I think this is too heavyweight.  With the
> infrastructure we have at the moment although users can go through
> upgrades there is some hassle.

While I don't like .bzrrules being versioned as a user file, I raised an
entirely orthogonal problem here - the content in the tree is
incompatible between a filtered tree and an unfiltered tree; historical
trees are really unrelated. Ian seemed to agree with me about this issue
in his reply to my review.

> I think we have already talked about this and I'd like to just go
> ahead as it is.
>
> In future perhaps we need an alternative mechanism to format markers,
> which would allow us to mark that a particular bzr version or
> capability is needed, without making the user upgrade before they can
> use that feature.  Perhaps this is equivalent to adding a new format
> and automatically upgrading when needed.

Possibly. Seems like a spectacularly bad idea to me, given my experience
with other systems (e.g. svn) that do this.

FWIW I'm currently prepping a full set of repository format bumps, and
we're requiring one for stacking, and will have a default bump change in
the near future too. So trying to avoid a bump for a specific feature
when there are a tonne in the pipeline seems redundant to me.

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080720/de61c834/attachment.pgp