[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [RFC] Compatibility - 1.6 svn with 1.7 libs [was: svn commit: r953428]

From: Greg Stein <gstein_at_gmail.com>
Date: Fri, 11 Jun 2010 05:34:48 -0400

svn_wc_private.h has seen massive changes in 1.7. A 1.6 libsvn_client
will not function against 1.7 libraries at all.

We said a while back that the svn executables and libraries should be
upgraded/downgraded/patched as a group. These internal dependencies
will (thus) remain in sync across the link units.

The fact is: we are sloppy with versioning guidelines on private APIs.
Third-party code using our public APIs receive all of our strict
guideline benefits.


On Fri, Jun 11, 2010 at 05:26, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> A question on removing a private API.
> In v1.6.5 (r878898) we added the API "svn_opt__eat_peg_revisions()" and
> called it from the command-line client.  This means 1.6.(>=5) 'svn' is
> not compatible with 1.6.(<5) libraries.
> What we should have done is to make it a private function within the
> client code, not in the libraries.  But that's history and we can live
> with it.
> In r953428 on trunk I have moved the function out of the libraries into
> the client code.[*]  (We are allowed to introduce new library functions
> on trunk, of course, but we don't want to keep this particular function
> in the API long term.)
> A consequence is that we will not be able to run svn 1.6.(>=5)
> executables against 1.7.x libraries.  It would be useful to do so for
> testing, of course.
> The questions are:
> How well can we test 1.6.x (or older) 'svn' against newer libraries
> anyway?  Are there other private-API changes that make it impossible
> without special compatibility code insertions?  Has anyone tried?
> Do we want to put this private API back into the 1.7 libraries for
> compatibility testing purposes or for any other reason?
> ([*] Note: Also in the same commit I removed the public name
> svn_opt_eat_peg_revisions() but that is not a concern because it has not
> been published in any way.)
> - Julian
> On Fri, 2010-06-11, Philip Martin wrote:
>> julianfoad_at_apache.org writes:
>> > Author: julianfoad
>> > Date: Thu Jun 10 19:49:22 2010
>> > New Revision: 953428
>> > * subversion/libsvn_subr/opt.c
>> >   (svn_opt__eat_peg_revisions): Remove this wrapper, as compatibility for
>> >     1.6 for svn executable is not required.
>> Why is this not required?
>> We abused the API guidelines by adding this to the 1.6 branch (it
>> should have been added to the command line client code).  We can work
>> around that by keeping the symbol available.
>> Keeping it also helps with backward compatibility testing.  We have
>> vastly more backward compatibility code in 1.7 compared to earlier
>> releases.  Being able to run the 1.6 client with 1.7 libraries seems
>> like a good idea to me.  How much do you think works at present?
Received on 2010-06-11 11:35:24 CEST

This is an archived mail posted to the Subversion Dev mailing list.