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

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

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Fri, 11 Jun 2010 10:26:06 +0100

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:26:48 CEST

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