[RFC] Improvements to is_ignored.
Robert Collins
robertc at robertcollins.net
Sat Jan 21 07:58:39 GMT 2006
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.
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/20060121/4f12936a/attachment.pgp
More information about the bazaar
mailing list