[RFC] Improvements to is_ignored.

[Jan Hudec]

On Sat, Jan 21, 2006 at 18:58:39 +1100, Robert Collins wrote:
> On Sat, 2006-01-21 at 14:27 +1100, Martin Pool wrote:
> > I suppose we could have some marker of how the things are to be
> > interpreted: old-style globs, new globs, regexps, etc.  But that might
> > be overkill for now.
> 
> Aaron and I had a long chat on IRC about this. It seems there two
> routes: one is such a marker for the version of such things that are
> stored in versioned files. (We could use one marker per file, or one
> marker for the set of 'versioned control files'). A different approach
> is to move .bzrignore from being a versioned control file to being
> versioned data - like inventories, revisions and texts, something wholly
> under the control of bzr, where the only guarantee you have is that the
> behaviour is retained, not that the representation or syntax is
> constant. That is - we can in principle generate a new-style glob
> representation of the ignore rules, just like we reserialise inventories
> when upgrading a branch. 
> 
> A small amount of logic would be needed to move .bzrignore from being a
> versioned file to versioned data in a branch upgrade - and (obviously?)
> to warn if doing a commit that has a .bzrignore.
> 
> I feel quite strongly though that this is not a trivial case to bypass
> the general principle: tree ignore rules matter a great deal to some
> folk, and if we can (and we can, with only modest effort) ovoid breaking
> them, lets do so.

Ok. I can see 3 ways to go:

1. Add some 'directives' in .bzrignore. So that new .bzrignore,
   generated by first use of 'bzr ignore', would start with something
   like:
    #style shell
    #defaults no
   which would tell bzr to interpret the patterns as (more) shell
   compatible and that defaults should not be added (because 'bzr
   ignore' would splice them here).

... and the two already outlined above:

2. Add a revision property telling whether it uses new or old style
   .bzrignore. If it was set to old, 'bzr ignore' would upgrade
   .bzrignore, add the default ignores and set it to new. is_ignored
   would choose semantics based on it's value.

3. Make it versioned data, wholly under control of bzr. That's hardest
   part, because it needs extending the 'bzr ignore' command to allow
   full manipulation with the data (I'd like to see that anyway, but in
   the other cases it can wait until later) and because it needs to add
   the logic for handling that data.

What do you folks think would be the best approach?

I think 1. would be easiest, but complicate things for the user a bit.
2. should still be pretty easy. Perhaps the advantage of 3 would be that
we won't have control files lying around the tree and that we could
change the storage without impact on the user.

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060130/530c9eb6/attachment.pgp