Greg Stein wrote:
> 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.
Yup, but just to clarify, here I'm not talking about mixing one version
of libsvn_client versus the other libs, but rather the client executable
as in "subversion/svn/*.c" versus "the set of libraries"...
> 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.
... but yes, that's what I was thinking, if I understand you right.
The question of whether we want to try running svn 1.6 against libs 1.7,
for our own interest, still remains.
- Julian
> 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?
> >
> > 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:55:05 CEST