rsync release planning

[Wayne Davison]

On Sat, Jul 05, 2003 at 10:30:13PM -0700, jw schultz wrote:
> I'll tell you what i'm thinking road map wise and you can
> agree or disagree, and tell me i'm crazy.
> 
> I'd like 2.5.7 fairly soon containing:
> 
> 	cygwinhang patch -- if testing shows it to be safe
> 		and effective.

I assume you mean adding this patch to what's currently in CVS?  Or do
you mean you'd like to create a branch of 2.5.6 with just this fix?  I'm
assuming you mean the former.

> Then i'm inclined to a 2.6.0 with these things that change
> the user interface:
> 
> 	my keyword based report (verbosity) option.
> 		This doesn't break anything and i have no
> 		qualms with it going into 2.5.8
> 
> 	ssh as default -rsh transport.
> 		This would affect users expecting rsh or remsh
> 
> This new pattern matching would fall into the changed UI
> that might merit a minor version number increment.

Since there are existing exclude changes that have a user-visible effect
already in CVS, I'd like to make sure that these changes get grouped
together with the "**" vs "*" change that the wildmatch code implements.
That could mean either undoing some user-visible changes in CVS (see
below) or going ahead and adding the wildmatch stuff to what's there.

Here are the current user-visible changes to the exclude code:

  - **/foo now matches /foo.

  - A non-anchored wildcard name with an interior slash properly floats
    at the end of the path.  I.e. CVS/R* matches the R* files in all CVS
    dirs, whereas it used to be treated as /CVS/R*.

  - foo**bar is now matched against the whole path, not just the
    filename.

The remaining change:

  - a "**" in the string no longer makes "*" match a slash.

> I'm also wondering about the craigb-perf patch.  Anyone know
> how widely it has been tested?

I've been wondering about it as well.  I've looked over the whole patch
and the comments and it certainly looks reasonable, but I am slightly
concerned about potential deadlock issues, though.  I haven't tested it
yet, nor have I tried to think through the I/O issues in depth yet.  The
change to reduce the calls to gettimeofday() looks easy to add, though,
and should really be separated out of the patch.  I've just checked in
some changes to tweak this.

..wayne..