Subversion-1.0.1-1 test package ready
Mon Apr 26 15:47:00 GMT 2004
Dave Slusher wrote:
> Quoting Max Bowsher <email@example.com>:
>> Subversion is not a dropin replacement for cvs. More of an evolutionary
>> replacement, really.
> I got all that text from some Subversion docs or web pages that may well
> changed since I collected it last fall. I can change it to whatever. What
> do you want changed and to what?
Don't call it a dropin replacement, because there is a learning curve from
cvs to subversion.
The following text, paraphrased from the subversion website, seems
"Subversion is a new version control system that aims to be a compelling
replacement for CVS in the open source community."
And/or copy your ldesc from setup.hint into README.
>> The list of installed files in the README is somewhat incomplete.
> Is this supposed to be a complete manifest of every file or just the high
> points? Tell me what files you think should be there that aren't and I'll
Personally, I'd just remove the file list from README. If people care, they
can always "zless /etc/setup/subversion.lst.gz".
>> It is unusual to place the cygwin build script within the package source
>> tree itself.
> The subversion source tree already has scripts and Makefile for building a
> number of different distributions, RPMs and the like. This seems
> analogous to me.
Entirely analogous with subversion, but not analogous with usual Cygwin
packaging methodologies. But anyway, this isn't a complaint, merely an
observation that you may be making things more difficult for yourself by
using generic-build-script in a way unlike most packagers.
OK, that's the prior few points dealt with, onto the new points.
* Your patch contains autom4te cache directories. These are generated files
which serve only to bloat the source package.
* The package is a client only build. This means it is impossible to create
local repositories!. There isn't really any reason to enforce this
restriction, when Cygwin already ships with Berkeley DB. Granted, 4.1 has
been reported as potentially buggy, but you could still use it for test
packages, whilst gently reminding the Cygwin BDB packager that there is an
new version to be packaged.
* The package bundles multiple (neon, apr, apr-util) dependent libraries
into the subversion package. I'm not sure this is a good idea - each of the
above libraries really should have a package of its own.
* The package uses static linking. Dynamic linking (DLLs) is a great
space-saver, especially for packages which contain as many libraries as
Well, that's plenty to talk about for the moment!
More information about the Cygwin-apps