include/exclude bug in rsync 2.6.0/2.6.1pre1

[Wayne Davison]

On Sat, Apr 10, 2004 at 03:05:15PM +0200, John Bowman wrote:
> If you decide later that you don't want foo.c, you can always tweak it
> locally using --rsync-exclude (which works recursively, similar to
> .htaccess files in Apache).

Not with the patch you supplied.  If the server's rules included the
file, no other user rules would have been checked to see if the user had
excluded it.  In a similar way, if the user's rules had included the
file (say, to make an exception to a user rule that would have exclude
it, but not to override anything else) it could not be excluded by an
entry in a .cvsignore file.

> I want to specify general system-wide rules with --exclude but
> (recursively) override them in local directories

Yet you don't supply a solution for the conundrum I posed.  Without
that, the current scheme is as good as it can be:  includes are for
excepting excludes in the current list, not for overriding excludes
from other lists.

You're also looking at the problem too narrowly.  If the user specifies
--exclude=\*.c , do we really want an include from a local directory to
be able to override that?  I don't.  Sometimes the excludes are not
"general system-wide rules", but instead very specific, "I don't want
this kind of file in this transfer" rules.  Trying to figure out which
rules are which is why this isn't an easy problem.

One potential solution to the proposed conundrum would be to have a
different include character for the two different kinds of includes.
For instance:

++ /path/we_REALLY_want_this_file_no_matter_what
+ /path/just_excepting_the_following_rule.c
- /path/*.c

This introduces a minor incompatibility (for files starting with
"++ ") and the extra idiom makes things more complex, so may not
be a desirable way to go.  It could also lead to the desire for
a "-- " prefix that would be strong enough to override a local-
file's "++ " rule, which would make things really complex.

> But as pointed out above, the current behaviour is not what most
> people would expect.

I disagree that first-match-wins is not what people expect -- it may not
be what everyone expect at first glance, but it's no harder to under-
stand than last-match-wins, and other things also use the first-match
idiom -- e.g. case in bourne shell, match rules in .procmailrc, etc.

..wayne..