Performance testing of ignore changes?

John Arbash Meinel john at arbash-meinel.com
Mon Jan 4 20:14:11 GMT 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Whitley wrote:
> John Arbash Meinel <john <at> arbash-meinel.com> writes:
> 
>> [Lots of good info on timing.]
> 
> Great, thanks.  I'll dig into that and see what shows.
> 
>> Another possibility is to have exact matches take precedence over
>> pattern matches. So if you have:
>>
>> # ignore everything
>> *
>> # but not foo
>> !foo.html
>> # Locally, we want to version build results
>> !**/*.o
>> # But not this one
>> foo/bar.o
>>
>> So the priority checking would be
>>
>> 1) Pattern matching ignores
>> 2) Pattern matching don't-ignore
>> 3) Exact matching ignores
>> 4) Exact matching don't-ignore
>>
>> *I* probably prefer that to !! syntax.
> 
> I'd thought of specificity-based ranking, but that seemed suspect in terms of
> being computationally more expensive and maybe not user transparent.  My initial
> implementation was purposely biased to be a simple extension of the existing
> code.  This is an interesting compromise, but it doesn't cover cases like this:
> 
> ---
> # ignore everything
> *
> # but not ~/local/share/emacs
> !~/local/share/emacs
> !~/local/share/emacs/**/*
> # but leave out generated .elc files
> ~/local/share/emacs/**/*.elc
> ---
> 
> I think this would need specificity-based ranking and a clear definition of
> 'specificity' (and/or 'explain' code in the bzr ignore UI) to work as expected.
>  The '!!' (or equivalent) syntax has the benefit of being explicit.  I don't
> mind implicit (aka 'magic') so long as the semantics are clear and it creates a
> great user experience.  It's not yet clear to me whether that's achievable here.
> 
> -- John

I'll also note that I'm not really sure how to introduce this and worry
about backwards compatibility. If older bzr versions just ignore the '!'
line, that might be ok, though I have the feeling they will abort, and
possibly fail to read the whole file.

A different possibility is to use something like git's distributed
ignore files. IIRC you can put a file in any subdirectory to control how
the ignores will be processed, and you can choose to inherit or not the
containing dirs rules. In which case, at the top level you would have

# ignore everything
*

But in 'local' you would have
# reset, since the container ignores everything
!
# Only ignore generated .elc files
*.elc

This is certainly more complex, and I'm not convinced it is the best way
forward. However, it would make round-tripping the git rules easier. :)

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktCTBMACgkQJdeBCYSNAAMLCwCg2VX6+4ji1ig5Szw4mR1YRloc
DcgAnAwsvtY6A0mpdgf6szfEPfEJqPBC
=zi4F
-----END PGP SIGNATURE-----



More information about the bazaar mailing list