Performance testing of ignore changes?

[Eric Siegerman]

On Mon, 2010-01-04 at 18:53 +0000, John Whitley wrote:
> I'm working on ignore exclusions[1]

Cool!

> But what happens when we note that .zcompdump is a file generated by
zsh, which
> shouldn't be versioned?  Ideally we'd like to ignore it.

The only reason you can't do that (without introducing "!!" or
the like) is because:
> Exclusion patterns take precedence over regular ignore patterns,
regardless
> of order in .bzrignore.

So make the list ordered, and all will be well, without needing
to add a double-negative operator to the syntax.

With last-match-wins ordering, the file looks almost like your #3
-- only the "!!" on ./.zcompdump is removed:

--- sample .bzrignore #4 ---
        # ignore everything
        *
        # except this stuff
        !./local
        !./local/**/*
        !RE:^\.z.*
        # but we really didn't want this
        ./.zcompdump
--- end sample #4 ---

Personally, I *much* prefer first-match-wins ordering.  Suppose
one is reading .bzrignore with a particular file in mind, to
figure out whether it will be ignored or not.  With
last-match-wins, one must:
  - remember which rule matched
  - keep reading
  - if there's another match, update one's mental "cursor"
  - at EOF, hope one didn't forget the cursor :-/

But with first-match-wins, one can simply stop reading at the first
match.

First-match-wins ordering leads to:

--- sample .bzrignore #5 ---
        # most files starting with .z are hand-edited, but .zcompdump
        # is generated
        ./.zcompdump
        !RE:^\.z.*
        # Other stuff that needs to be tracked
        !./local
        !./local/**/*
        # ignore everything else
        *
--- end sample #5 ---


On a related note, I find "!" confusing.  There's already an
implied negative -- .bzrignore currently says which files *not*
to track, so "!foo" says "don't not track foo" (and "!!foo" would
say "don't avoid not tracking foo" -- a triple-negative).

Much clearer to let the user explictly say "track" or "ignore".

One possibility would be a simplified, and slightly modified,
variant of rsync's filter syntax.  (Note that I'm absolutely
*not* suggesting rsync's insanely baroque rules for individual
patterns and the like -- only the basic "rule<whitespace>pattern"
line syntax.

Removing the now-superfluous comments:

--- sample .bzrignore #5 ---
        # most files starting with .z are hand-edited, but .zcompdump
        # is generated
        track  ./.zcompdump
        ignore RE:^\.z.*

        track  ./local
        track  ./local/**/*
        ignore *
--- end sample #5 ---

Of course the default must be "ignore".

Note the required whitespace, which should reduce
backward-compatibility issues at least to the same level as
"!foo" syntax.


It would be good to allow "+" and "-" operators, as rsync also
does, but there's a problem.  In a file called ".bzrignore", with
it's implied negative, "+" needs to mean "ignore", leading to
the horrid:
        - ./.zcompdump
        + RE:^\.z.*

Yikes!

OK, so maybe the "+" and "-" short-forms should wait for a
suitably-named file in .bzrmeta, where there would be no
backward-compatibility issue at all as far as the file's syntax
is concerned.  That way, "+" and "-" could mean what my brain
wants them to mean:
        "+" == track  == include
        "-" == ignore == exclude

--- sample .bzrmeta/filter-rules[*] ---
        # most files starting with .z are hand-edited, but .zcompdump
        # is generated
        + ./.zcompdump
        - RE:^\.z.*

        + ./local
        + ./local/**/*
        - *
--- end sample ---

[*] for example.  I'm not fussed about the file's name, as long
    as it doesn't talk about "ignoring"


But even if you stick with "!", please make the list ordered, so
you don't have to introduce a triple-negative operator!

  - Eric