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