This is the mail archive of the
mailing list for the Cygwin project.
Re: librsync in setup
Robert Collins wrote:
> On Wed, 2003-03-19 at 02:54, Max Bowsher wrote:
>> Several points:
>> 1) In 5 of the 6, *.input directories, there is a spurious extra
>> copy of the directory inside itself. I've checked with librsync cvs
>> - these directories have never existed upstream.
>> I propose to cvs remove these.
> Please do.
Going to do this now.
>> 2) Is setup-rsync development active at all? librsync was not
>> imported into CVS using a vendor branch
> I don't grok vendor branches...
>> , just checked in normally. No changes have yet
>> been made.
> Hmm, I thought I made changes relative to the upstream, to build
> cleanly on mingw. In fact, I'm positive of that.
OK, if you did, there is no evidence of the changes in CVS - perhaps you
integrated them before the initial checkin.
>> If there is active development, I suggest we act now to cvs
>> remove the plain-checkin librsync, and import the latest version
>> using CVS's vendor branch capabilities.
> What do vendor branches do that is different to a a checkin?
Their primary function is to be self-documenting about local changes made to
>> If there is no active development, I suggest we
>> cvs remove librsync, and do not import it until some development
>> begins. Whilst doing this, I suggest any new import be made under a
>> 'librsync' dir, not 'rsync'.
> I'm not to worried about the directory name. Don't forget to update
> /configure.in and /Makefile.am if you rename the directory.
> I'm not actively developing the rsync capability. It was one of those
> things where I thought that removing the greatest hurdle (hacing rsync
> logic available to setup) might lead to some other folk (i.e. the
> people asking for the feature) to hack on it....
OK. I'm going to analyse what local changes you made to librsync before
deciding what to do.