Here is the reply from upstream:

On Tue 26 Apr 2005, Wayne Davison wrote:

> On Tue, Apr 26, 2005 at 10:25:14AM +0200, Paul Slootman wrote:
> > I wouldn't have expected 2.6.4 to refuse to talk to even a 2.6.2 in
> > this way...
> 
> It shouldn't, and (interestingly) it wouldn't have if --delete had been
> specified (apparently I did all my backward-compatibility testing using
> --delete).
> 
> So, it turns out to be a bug in the filter-compatibility code when we're
> a client sender and we're not actually sending the filter list to the
> receiver (which we don't in older protocols when we're the sender and
> --delete wasn't specified), but instead just verifying that it doesn't
> contain any directives that were too new to work with the remote rsync.
> 
> Attached is the fix.
> 
> ..wayne..

> --- exclude.c 7 Apr 2005 18:06:06 -0000       1.115
> +++ exclude.c 26 Apr 2005 15:18:45 -0000
> @@ -1108,7 +1108,7 @@ static void send_rules(int f_out, struct
>                   && !(ent->match_flags & MATCHFLG_MERGE_FILE)) {
>                       int f = am_sender || protocol_version < 29 ? f_out : -1;
>                       send_rules(f, &cvs_filter_list);
> -                     if (f >= 0)
> +                     if (f >= 0 || f_out < 0)
>                               continue;
>               }
>               p = get_rule_prefix(ent->match_flags, ent->pattern, 1, &plen);

This will be fixed in 2.6.4-4 that I'm now building.


Paul Slootman


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to