librsync in setup

[Max Bowsher]

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
external sources.

>>  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.

Max.