Performance testing of ignore changes?

[Robert Collins]

On Wed, 2010-01-06 at 10:54 -0500, Eric Siegerman wrote:
> 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.

An ordered style, allowing interleaving would lead to a list of regexes,
rather than (with exclusions) at most 2 regexes. We apply ignore logic
inside the inner loop of status, and we don't currently cache the result
of that. I'm extremely concerned about the potential for regressions on
100000 file trees - take a 100K file tree, with 50K ignored artifacts:
adding one regex takes us from 50K to 100K regex matches; adding an
arbitrary list of regexes will permit users to create slow performing
environments unless they understand all the internals and know exactly
what is going on: users would be able to make bzr perform badly while
doing a normal operation.

In the absence of detailed data, I'd like to suggest that the simple two
sets (ignore, exclude-from-ignores) patch that John is working on is a
same middle ground: it adds the feature, doesn't block on needing a new
cache of ignored files, and will scale well.

-Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20100107/57957950/attachment.pgp