This is the mail archive of the
mailing list for the Cygwin project.
Re: Fwd: Subversion packages
- From: "Yaakov (Cygwin/X)" <yselkowitz at users dot sourceforge dot net>
- To: cygwin at cygwin dot com
- Date: Mon, 18 Nov 2013 14:32:20 -0600
- Subject: Re: Fwd: Subversion packages
- Authentication-results: sourceware.org; auth=none
- References: <CAFMYRRMFGxJhMKNKVgUEs45Lb5dLCf-5vq+Rp5s0H=Eg1yB5kw at mail dot gmail dot com> <CAFMYRRPZWqSJWZVVGDQLLZ55ZOcD_H9q7UgPr4iZyKw9vr2TbQ at mail dot gmail dot com> <52890843 dot 90903 at acm dot org> <CAFMYRRPt+9U_GcrRwQoOPn4OxpqmW44uy4stp-auX+KYg4pr8w at mail dot gmail dot com> <528A5E0E dot 7000906 at acm dot org>
On 2013-11-18 12:35, David Rothenberger wrote:
Kevin Connor Arpe wrote:
I was thinking about this type of SVN package setup:
* 1.6.x (svn_1.6)
* 1.7.x (svn_1.7)
* 1.8.x (svn_1.8)
* svn (latest -- currently svn_1.8)
I could create statically linked binaries that can live side-by-side,
e.g., /usr/bin/svn1.6, svn1.7, svn1.8 and plain old "svn" which is the
I'm strongly against statically linking the binaries. It produces
very large binaries and will require recreating the binaries any
time a bug is fixed in any of the many dependent libraries. It also
does not address the API bindings which require DLLs to function,
for example the Perl binding used by git-svn. There is also the
Apache module to consider.
There are also a number of svn-dependent components in Ports which link
against libsvn*-1, so the shared libraries cannot simply go away.
I suppose you could have a system where the versioned svn packages
provide only a statically linked binaries and none of the other
libraries, while the unversioned Subversion packages provide
dynamically linked binaries and all the libraries.
*Iff* supporting multiple versions is deemed necessary, this would be
the way to go.
I know of no other Linux distribution that supports multiple
installed versions of Subversion. I don't think it's a good idea.
Me neither, but given the recent sqlite3 locking discussion, I won't be
surprised if compatibility with native Windows clients trumps that.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple