Re: [RFC] Compatibility - 1.6 svn with 1.7 libs [was: svn commit: r953428]

[Greg Stein <gs...@gmail.com>]

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 <ju...@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:
>> julianfoad@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?
>>
>
>
>

Re: [RFC] Compatibility - 1.6 svn with 1.7 libs

[Philip Martin <ph...@wandisco.com>]

Julian Foad <ju...@wandisco.com> writes:

> Ah, you added that svn_opt__eat_peg_revisions() forwarding function
> specifically to support this?  Now I understand where you're coming
> from.

You may not have realised, but svn_opt__eat_peg_revisions didn't have
a visible prototype outside the library source file.  Nothing could
compile against it (well not without a warning or creating a
prototype), it just existed to satisfy the depenency at run time.

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

No.

-- 
Philip

Re: [RFC] Compatibility - 1.6 svn with 1.7 libs

[Julian Foad <ju...@wandisco.com>]

On Fri, 2010-06-11 at 11:19 +0100, Philip Martin wrote:
> Greg Stein <gs...@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 <ju...@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?
> 

Re: [RFC] Compatibility - 1.6 svn with 1.7 libs

[Philip Martin <ph...@wandisco.com>]

Greg Stein <gs...@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 <ju...@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

Re: [RFC] Compatibility - 1.6 svn with 1.7 libs [was: svn commit: r953428]

[Greg Stein <gs...@gmail.com>]

On Fri, Jun 11, 2010 at 05:54, Julian Foad <ju...@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

Re: [RFC] Compatibility - 1.6 svn with 1.7 libs [was: svn commit: r953428]

[Julian Foad <ju...@wandisco.com>]

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

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

- Julian


> 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 <ju...@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:
> >> julianfoad@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?
> >>
> >
> >
> >