On Fri, Jun 11, 2010 at 05:54, Julian Foad <julian.f...@wandisco.com> wrote: > 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"...
Yes. And it might be a little easier because the svn cmdline doesn't take strong advantage of these internal/private APIs. But the overall logic still holds: we've revamped internal APIs that preclude mix/match. ... hmm. Thinking on this, our inter-library dependency check allows for "newer" libraries to pass the check. But that isn't true if some private APIs are no longer available. Ugh. >> 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. It is *very* interesting. But... it's going to be hard. There were some private entries-based functions that we've eliminated. Those would need to be resurrected in some fashion. I'd like to be able to try running 1.x against a 1.7 wc library (and that impiies 1.7 of subr/diff/delta) to ensure that our backwards-compat code is Good. Cheers, -g
