On Fri, Jun 11, 2010 at 05:54, Julian Foad <julian.foad_at_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
Received on 2010-06-11 12:04:43 CEST