Re: svn commit: r953428 - in /subversion/trunk/subversion: include/ libsvn_subr/ svn/

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

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?

-- 
Philip

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

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

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

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

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