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 <julianf...@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: > >> julianf...@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? > >> > > > > > >
