[RFC] Improvements to is_ignored.

[Martin Pool]

On 30 Jan 2006, Jan Hudec <bulb at ucw.cz> wrote:
> 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. 

But the question is, *what* behaviour is retained?  If someone asks to
ignore '*.c' do they really want that to be changed into '(*|.*).c'
because we used to suffer that bug from fnmatch?

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

I think #1 is reasonable, though I would still want to ask whether
anyone actually wants the old buggy behaviour.

I see the question of whether this is stored in .bzrignore or in a
directory property or elsewhere as being somewhat orthogonal to how the
rules are interpreted.  Whereever it is stored, we have a choice of 

 - just interpreting using the current glob engine
 - rewriting rules into a new style
 - or putting in an indication of how they should be interpreted

It's somewhat useful for people to be able to comment out rules, or add
descriptive comments, which pushes me towards treating it as a
human-created source file, whereever it lives.

-- 
Martin
-------------- 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/87a0ab40/attachment.pgp