Greg Stein <gst...@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 client? > 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 <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? 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 Yes. >> or for any other reason? -- Philip
