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.
