On Fri, 2010-06-11 at 11:19 +0100, Philip Martin wrote:
> Greg Stein <gstein_at_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 <julianfoad_at_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.
Ah, you added that svn_opt__eat_peg_revisions() forwarding function
specifically to support this? Now I understand where you're coming
from.
OK, perhaps we'll re-add this. And/or make it a non-library function in
1.6.(>=12) so that at least we'll be able to test *some* versions of
1.6.x.
Any preference? (My preference is something like the latter, because I
really odn't want us to keep that particular function: I want to get rid
of even the non-library version of it soon.)
- Julian
> >>
> >> Do we want to put this private API back into the 1.7 libraries for
> >> compatibility testing purposes
>
> Yes.
>
> >> or for any other reason?
>
Received on 2010-06-11 12:36:09 CEST