[fixed] ignore problem

[Martin Pool]

On 7 April 2011 13:51, Andrew Bennetts <andrew.bennetts at canonical.com> wrote:
> I think the main reason we don't support a .bzrignore file per directory
> is performance: having to search for many files is going to be much
> slower than looking for exactly one.  Also it would probably be a bit
> more complex to efficiently compile the rules into single regex if they
> came from multiple sources found as we walked the tree during a 'bzr st'
> or 'bzr add' (and walking the tree completely in advance just to find
> any per-directory ignore files would definitely hurt performance).

I think just looking for the file would probably not hurt performance,
if it was done well.  If we look for it only when we're checking for
unversioned files in a subdirectory D, we will have already loaded the
directory D and checking whether there is a .bzrignore in it should be
very nearly free on Unix. We would have to be careful not to, for
example, load all the ignore files up front and then separately scan
the tree because for sufficiently big trees that could hurt.

We may need some physical IO to actually load the file but that's
perhaps more reasonable because the user's chosen to put it there.
We'd want to avoid the poorly scaling case of (old?) svn where you
repeat '*.o' in every sub directory of course.

The other thing you mention, compiling the matchers, would possibly be
more of a problem, but we could probably make it scale reasonably
close to the complexity of what the user specified.

So we could add it.  But going back to the original question, I'm not
sure this would overall reduce the number of people who ignore things
they don't want to.  I'm reminded of the saying that plain old unix
permissions (rather than acls) are about as much complexity as most
people can understand most of the time.

-- 
Martin