[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

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Fri, 11 Jun 2010 11:19:45 +0100

Greg Stein <gstein_at_gmail.com> writes:

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

It depends what you mean by "at all".

svn up up -r953427 ../src
./config.nice --disable-full-version-match
make -j3
for i in subversion/libsvn_*/.libs/libsvn_*so.0.0.0;do cp $i ../obj-1.6/$i;done
cd ../obj-1.6

Now I have a 1.6 client with 1.7 libraries. It works well enough to
checkout and commit.

rm subversion/libsvn_client/libsvn_client-1.la
make libsvn_client

Now I have a 1.6 svn client and 1.6 libsvn_client with all other 1.7
libraries. It works well enough to do a checkout but wc locks get
left requiring cleanup to be used.

Commit fails with an abspath assertion. That could mean that we are
missing an abspath conversion and so allowing a 1.6 non-abspath into
our 1.7 libraries. We need to test for that sort of thing before
realeasing 1.7. How will we do that if we can't even run our own

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

I'd certainly agree that we only support upgrading all the libraries
together. I like to allow the libraries to be upgraded without the
client since that is what we expect other people to do, although I
don't think we should support it as such.

> 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.
> Cheers,
> -g
> 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?

I fixed two problems some time ago: svn_opt__eat_peg_revisions that
allows the 1.6 client to use the 1.7 libraries and one other that
allows 1.6 libsvn_client to use the 1.7 libraries.

>> Do we want to put this private API back into the 1.7 libraries for
>> compatibility testing purposes


>> or for any other reason?

Received on 2010-06-11 12:20:42 CEST

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