[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:
> > However I don't think it really applies to this case of ignore lists: it
> > may mean some files were ignored-but-added when they previously weren't,
> > or vice versa.  You can still check out the revision, modify the files
> > and make a new commit.  The only difference as far as I can see is that
> > if you do a build in that directory then some build products may be
> > unknown rather than ignored; or conversely some newly added files will
> > be ignored when they shouldn't be.  So at that point you'd have to fix
> > up the ignore list, but that seems reasonable because you're now
> > starting to do new work.
> 
> Well, thats the question - are you working with an old variant to do new
> work, or to (for instance) recreate an old build. Any system that looks
> for clean tree lints will break in the latter case.
> 
> > 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.

* Ignore rules matter a grat deal to some folk, but it is not that likely
  that the semantics of existing globs will actually change. Most globs are
  simple *.o and .*.sw[nop] and these will not change.
* The ignore semantics is currently broken in other ways (eg. always
  including the defaults), so I am not sure anyone actually uses it.
  I believe that's one more thing that *is* going to change.
* Bzr is still beta software. It can afford to change semantics now to have
  it right when it's released.

-- 
						 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/20060121/9564b11a/attachment.pgp