[Bug 2240] Add last-match/short-circuit processing of include/exclude

samba-bugs at samba.org samba-bugs at samba.org
Thu Jan 13 21:26:16 GMT 2005


https://bugzilla.samba.org/show_bug.cgi?id=2240


wayned at samba.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED




------- Additional Comments From wayned at samba.org  2005-01-13 14:26 -------
I'm not totally sure what you mean by "arbitrary nesting of matches", but I'll
assume that you're talking about being able to override the rules of a
.cvsignore file (which is not currently possible) and to string together
multiple generic --include-from/--exclude-from files on the command-line and
have some of the files specify a rule that will override the rules of a later
file (or earlier, depending on the order of the scan). This is something that
was talked about before, and I think that it would be a nice idea to add
something like this to rsync. Your syntax choice looks like a good one.  (I had
previously suggested using "++ pattern" instead of "+! pattern", but I like "+!"
better).

This does mean that an incompatibility in the syntax of exclude files is
introduced (e.g. a file named "+! foo" was not previously special). I'm thinking
that it would be a good idea to make the code escape all names that start with
"+" or "-" (e.g. prefix "+ " or "- ", as appropriate). This would allow the
adding of any non-space suffixes to the initial "+" or "-" to change their
meaning without adding any new incompatibilities in the syntax of the
include/exclude files. I think I'll go ahead and add this to the code that sends
the name over the socket, as it does not interfere with backward compatibility
(and improves forward compatibility).

As for the order of the includes/excludes, the same logic can be implemented in
either order, so we need some other reason besides adding a new short-circuit
syntax to change it. For instance, your patch can be thought of as implementing
first-match on the short-circuit rules, and falling back to last match on the
rest of the rules (and .cvsignore files must get added at the bottom of the list
of rules). In the current rsync order this would be implemented as a priority
last-match of the short-circuit rules, followed by first-match of the normal
rules (and .cvsignore files continue to be added at the top of the list of
rules). So, a --last-match option should only be added if we wish to give the
user the option of writing their rules in the opposite order, and I'm not sure
we need that.

As for the implementation, I'd prefer to see one that doesn't always match every
name against every item in the list (if we can help it). We can do this by
adding a "previous" pointer to the exclude_struct so that it can be scanned in
either order. The code would then scan in one direction for just the
short-circuit rules (if any exist), and then fall back to scanning in the
opposite direction for normal rules. If the --last-match option was still
desired, I would make its only affect be to change the order of how the user's
items get put into the list (so that the same scanning code could be used for
both modes).

I'm currently considering some changes to the include/exclude code: namely a
modified version of the current merge-exclude-file.diff in the patches dir, but
with the syntax of the include-rule lines changed. Thus, the addition of a new
"overriding" include/exclude idiom would go well with this.

-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.


More information about the rsync mailing list