Reviewing 1.10 APIs & compatibility

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Reviewing 1.10 APIs & compatibility

Julian Foad-5
One task in the 1.10 release process is reviewing API changes.

One way, that I use myself, is to take a library at a time and compare
the 1.9 and 1.10 public headers, looking for procedural errors (e.g. how
new and deprecated APIs are marked up, undocumented parameters, etc.)
and for possible semantic problems such as changing one part of the API
but not changing a related part in the corresponding way.

Another possible approach is to look for compatibility breakage by
running the 1.9 client and test suite against the 1.10 libraries, and
indeed different client/server version combinations.

Can anyone volunteer for any of this?

- Julian
Reply | Threaded
Open this post in threaded view
|

Re: Reviewing 1.10 APIs & compatibility

James McCoy-3
On Dec 5, 2017 10:27, "Julian Foad" <[hidden email]> wrote:
One task in the 1.10 release process is reviewing API changes.

One way, that I use myself, is to take a library at a time and compare the 1.9 and 1.10 public headers, looking for procedural errors (e.g. how new and deprecated APIs are marked up, undocumented parameters, etc.) and for possible semantic problems such as changing one part of the API but not changing a related part in the corresponding way.

Another possible approach is to look for compatibility breakage by running the 1.9 client and test suite against the 1.10 libraries, and indeed different client/server version combinations.


James

Reply | Threaded
Open this post in threaded view
|

Re: Reviewing 1.10 APIs & compatibility

Julian Foad-5
In reply to this post by Julian Foad-5
Julian Foad wrote:

> One task in the 1.10 release process is reviewing API changes.
>
> One way, that I use myself, is to take a library at a time and compare
> the 1.9 and 1.10 public headers, looking for procedural errors (e.g. how
> new and deprecated APIs are marked up, undocumented parameters, etc.)
> and for possible semantic problems such as changing one part of the API
> but not changing a related part in the corresponding way.
>
> Another possible approach is to look for compatibility breakage by
> running the 1.9 client and test suite against the 1.10 libraries, and
> indeed different client/server version combinations.
>
> Can anyone volunteer for any of this?

Any volunteers?

I have added this task to the pre-release check-list in
http://subversion.apache.org/docs/community-guide/releasing.html#release-branches

Filed as https://issues.apache.org/jira/browse/SVN-4716

If anyone has done or is doing any review please could you mention it
there so we can track it.

Thanks.
- Julian

Reply | Threaded
Open this post in threaded view
|

Re: Reviewing 1.10 APIs & compatibility

Julian Foad-5
Julian Foad wrote:

> Any volunteers?
>
> I have added this task to the pre-release check-list in
> http://subversion.apache.org/docs/community-guide/releasing.html#release-branches 
>
>
> Filed as https://issues.apache.org/jira/browse/SVN-4716
>
> If anyone has done or is doing any review please could you mention it
> there so we can track it.

I did a read-through comparison between branches/1.9.x and trunk of
subversion/include/*.h concentrating on the new and changed doc strings
(but not thoroughly reviewing the long ones) and Doxygen mark-up.

I committed a few tweaks in r1821183.

- Julian
Reply | Threaded
Open this post in threaded view
|

Re: Reviewing 1.10 APIs & compatibility

Philip Martin
In reply to this post by Julian Foad-5
Julian Foad <[hidden email]> writes:

> Julian Foad wrote:
>> Another possible approach is to look for compatibility breakage by
>> running the 1.9 client and test suite against the 1.10 libraries,
>> and indeed different client/server version combinations.

I did this recently.

1.9 against a 1.10 server
=========================

First I ran the 1.9 testsuite against 1.10 servers
over http:// and svn://.  For http:// there were two FAILs:

  FAIL:  lock_tests.py 34: unlock file locked by other user
  FAIL:  lock_tests.py 53: unlock a lock with timeout

In both cases the problem is the testsuite getting different error from
that expected:

  W: Unexpected output
  W: EXPECTED STDERR (regexp):
  W: | svn: warning: W160039: .*[Uu]nlock of .*403 Forbidden.*
  W: ACTUAL STDERR:
  W: | svn: warning: apr_err=SVN_ERR_FS_PATH_ALREADY_LOCKED
  W: | svn: warning: W160035: Path 'pi' already locked (423 Locked)
  W: | ../src-1.9/subversion/svn/unlock-cmd.c:100: (apr_err=SVN_ERR_ILLEGAL_TARGET)
  W: | svn: E200009: One or more locks could not be released

It turns out that both 1.9 and 1.10 servers return the same underlying
FS error: the W160039 expected by the testsuite.  The difference is that
the 1.9 server wraps it in a 403 while the 1.10 server wraps it in a
423.  The 1.9 client does not have r1716450 and that causes the 1.9
client to convert the underlying FS error to W160035.

For svn:// there were three FAILs:

  FAIL:  ra-test 1: test svn_ra_get_location_segments
  FAIL:  ra-test 4: lock multiple paths
  FAIL:  ra-test 5: test ra_get_dir2

In all cases these are caused by the server returning
SVN_ERR_FS_INCORRECT_EDITOR_COMPLETION due to a commit editor drive
failing to close directories, a testsuite bug fixed in 1.10 by r1665532.

1.10 against a 1.9 server
=========================

I also ran the 1.10 testsuite against 1.9 servers over http:// and
svn://.  In order to run the svn:// tests I had to disable part of
ra-test 10 as the 1.9 server doesn't have r1723865 and the 1.10
testsuite would block.

There were more failures than running 1.9 against 1.10 but a number were
functionaltity missing from 1.9 which is to be expected.  Both http://
and svn:// failed these tests:

  FAIL:  ra-test 8: delete revision newer than youngest
  FAIL:  ra-test 9: check how ra functions handle bad revisions
  FAIL:  basic_tests.py 67: null 'update' updates last changed rev
  FAIL:  basic_tests.py 68: null 'property update' updates last changed rev
  FAIL:  svnadmin_tests.py 48: upgrade --compatible-version=1.3
  FAIL:  svnadmin_tests.py 56: svnadmin dump with no-op property change

The first ra-test FAIL is a faulty commit that is only detected by 1.10.
The second ra-test FAIL is test for r1665308, a revision range check
that is not in 1.9.

The basic_tests FAILs are issue 4700 which is not fixed in 1.9.

The first svnadmin_tests FAIL is due to the test using a 1.10 format
repository.  The second svnadmin_tests FAIL is due to issue 4623 which
is not fixed in 1.9.

The http:// tests also failed:

  FAIL:  lock_tests.py 34: unlock file locked by other user
  FAIL:  mod_dav_svn_tests.py 1: verify 'Cache-Control' headers on responses

The lock FAIL is the same lock change that affects 1.9 but in
reverse, the 1.9 server sends 403 and the 1.10 testsuite expects 423.
The mod_dav_svn_tests FAIL is a new 1.10 feature not provided by the
1.9 server.

Summary
=======

Assuming the 1.10 behaviour of sending the 423 lock error is correct
then we cannot avoid the behaviour change for the 1.9 client and the
1.10 release notes should document it.  In the longer term I suppose we
could backport a client side fix to 1.9.

1.9 with 1.10 libraries
=======================

I built 1.9 and 1.10 with --disable-full-version-match and then I copied
the 1.10 shared libraries, i.e. libsvn_*-1.so.0.0.0, into the 1.9 build
overwriting the 1.9 libraries.  Running the 1.9 regression tests allows
testing of some of the ompatibility wrappers since the 1.9 binaries will
still call the top level 1.9 functions.  This does not test all the
wrappers, only those invoked directly by the binaries.

There are 42 FAILs running the tests over ra_local, and fs-fs-pack-test
appears to hang and needs to be killed.  I have not yet investigated any
of these failures:

FAIL:  cache-test 4: basic membuffer svn_cache test
FAIL:  cache-test: Unknown test failure; see tests.log.
FAIL:  fs-fs-pack-test 18: file with 0 expanded-length, issue #4554
FAIL:  fs-fs-pack-test: Unknown test failure; see tests.log.
FAIL:  fs-fs-private-test 3: load the P2L index
FAIL:  fs-fs-private-test 1: get statistics on a FSFS filesystem
FAIL:  fs-test 42: test svn_fs__compatible_version
FAIL:  fs-test 66: test rep-sharing on content rather than SHA1
FAIL:  op-depth-test 69: move/delete file externals (issue 4293)
FAIL:  parse-diff-test 9: test parsing unidiffs lacking trailing eol
FAIL:  ra-test: Unknown test failure; see tests.log.
FAIL:  repos-test 7: test authz access control
FAIL:  repos-test 10: test authz with global groups
FAIL:  repos-test: Unknown test failure; see tests.log.
FAIL:  utf-test 7: test svn_utf__fuzzy_escape
FAIL:  copy_tests.py 4: svn cp URL URL cannot overwrite destination
FAIL:  diff_tests.py 51: create a diff in git unidiff format for wc-wc
FAIL:  diff_tests.py 52: create a diff in git unidiff format for url-wc
FAIL:  diff_tests.py 53: create a diff in git unidiff format for url-url
FAIL:  diff_tests.py 56: create a diff in git format for empty files
FAIL:  diff_tests.py 57: create a diff in git format showing prop changes
FAIL:  diff_tests.py 68: create a diff in git unidff format for wc dir mv
FAIL:  externals_tests.py 44: move with file externals
FAIL:  externals_tests.py 48: file externals unversioned obstruction
FAIL:  patch_tests.py 13: patch target with no svn:eol-style
FAIL:  patch_tests.py 15: patch target with uncommitted svn:eol-style
FAIL:  patch_tests.py 20: apply the same patch twice
FAIL:  patch_tests.py 21: patch with dir properties
FAIL:  patch_tests.py 27: revert a patch by reverse patching
FAIL:  patch_tests.py 32: patch file lacking trailing eol
FAIL:  patch_tests.py 44: apply a patch to an empty file
FAIL:  patch_tests.py 45: svn diff created patch should apply without fuz
FAIL:  patch_tests.py 53: patch delete modified
FAIL:  patch_tests.py 54: find closest hunk
FAIL:  stat_tests.py 27: run 'status -u' with locally deleted directories
FAIL:  svnadmin_tests.py 24: svnadmin verify with non-UTF-8 paths
FAIL:  svnauthz_tests.py 8: test 'svnauthz accessof --is' on files
FAIL:  svnauthz_tests.py 9: test 'svnauthz accessof --is' on files and urls
FAIL:  svnfsfs_tests.py 1: load-index in a packed repo
FAIL:  svnfsfs_tests.py 2: stats on empty repo shall not crash
FAIL:  upgrade_tests.py 15: upgrade tree conflict data (f20->f21)
FAIL:  upgrade_tests.py 21: upgrade from format 28: rename pristines

--
Philip
Reply | Threaded
Open this post in threaded view
|

Re: Reviewing 1.10 APIs & compatibility

Julian Foad-5
Philip Martin wrote:
>> Julian Foad wrote:
>>> Another possible approach is to look for compatibility breakage by
>>> running the 1.9 client and test suite against the 1.10 libraries,
>>> and indeed different client/server version combinations.
>
> I did this recently.

Thank you Philip! Extremely helpful.

If you are pursuing any of the follow-on tasks here, let us know so I or
others can pick a different task.

- Julian


> 1.9 against a 1.10 server
> =========================
>
> First I ran the 1.9 testsuite against 1.10 servers
> over http:// and svn://.  For http:// there were two FAILs:
>
>    FAIL:  lock_tests.py 34: unlock file locked by other user
>    FAIL:  lock_tests.py 53: unlock a lock with timeout
>
> In both cases the problem is the testsuite getting different error from
> that expected:
>
>    W: Unexpected output
>    W: EXPECTED STDERR (regexp):
>    W: | svn: warning: W160039: .*[Uu]nlock of .*403 Forbidden.*
>    W: ACTUAL STDERR:
>    W: | svn: warning: apr_err=SVN_ERR_FS_PATH_ALREADY_LOCKED
>    W: | svn: warning: W160035: Path 'pi' already locked (423 Locked)
>    W: | ../src-1.9/subversion/svn/unlock-cmd.c:100: (apr_err=SVN_ERR_ILLEGAL_TARGET)
>    W: | svn: E200009: One or more locks could not be released
>
> It turns out that both 1.9 and 1.10 servers return the same underlying
> FS error: the W160039 expected by the testsuite.  The difference is that
> the 1.9 server wraps it in a 403 while the 1.10 server wraps it in a
> 423.  The 1.9 client does not have r1716450 and that causes the 1.9
> client to convert the underlying FS error to W160035.
>
> For svn:// there were three FAILs:
>
>    FAIL:  ra-test 1: test svn_ra_get_location_segments
>    FAIL:  ra-test 4: lock multiple paths
>    FAIL:  ra-test 5: test ra_get_dir2
>
> In all cases these are caused by the server returning
> SVN_ERR_FS_INCORRECT_EDITOR_COMPLETION due to a commit editor drive
> failing to close directories, a testsuite bug fixed in 1.10 by r1665532.
>
> 1.10 against a 1.9 server
> =========================
>
> I also ran the 1.10 testsuite against 1.9 servers over http:// and
> svn://.  In order to run the svn:// tests I had to disable part of
> ra-test 10 as the 1.9 server doesn't have r1723865 and the 1.10
> testsuite would block.
>
> There were more failures than running 1.9 against 1.10 but a number were
> functionaltity missing from 1.9 which is to be expected.  Both http://
> and svn:// failed these tests:
>
>    FAIL:  ra-test 8: delete revision newer than youngest
>    FAIL:  ra-test 9: check how ra functions handle bad revisions
>    FAIL:  basic_tests.py 67: null 'update' updates last changed rev
>    FAIL:  basic_tests.py 68: null 'property update' updates last changed rev
>    FAIL:  svnadmin_tests.py 48: upgrade --compatible-version=1.3
>    FAIL:  svnadmin_tests.py 56: svnadmin dump with no-op property change
>
> The first ra-test FAIL is a faulty commit that is only detected by 1.10.
> The second ra-test FAIL is test for r1665308, a revision range check
> that is not in 1.9.
>
> The basic_tests FAILs are issue 4700 which is not fixed in 1.9.
>
> The first svnadmin_tests FAIL is due to the test using a 1.10 format
> repository.  The second svnadmin_tests FAIL is due to issue 4623 which
> is not fixed in 1.9.
>
> The http:// tests also failed:
>
>    FAIL:  lock_tests.py 34: unlock file locked by other user
>    FAIL:  mod_dav_svn_tests.py 1: verify 'Cache-Control' headers on responses
>
> The lock FAIL is the same lock change that affects 1.9 but in
> reverse, the 1.9 server sends 403 and the 1.10 testsuite expects 423.
> The mod_dav_svn_tests FAIL is a new 1.10 feature not provided by the
> 1.9 server.
>
> Summary
> =======
>
> Assuming the 1.10 behaviour of sending the 423 lock error is correct
> then we cannot avoid the behaviour change for the 1.9 client and the
> 1.10 release notes should document it.  In the longer term I suppose we
> could backport a client side fix to 1.9.
>
> 1.9 with 1.10 libraries
> =======================
>
> I built 1.9 and 1.10 with --disable-full-version-match and then I copied
> the 1.10 shared libraries, i.e. libsvn_*-1.so.0.0.0, into the 1.9 build
> overwriting the 1.9 libraries.  Running the 1.9 regression tests allows
> testing of some of the ompatibility wrappers since the 1.9 binaries will
> still call the top level 1.9 functions.  This does not test all the
> wrappers, only those invoked directly by the binaries.
>
> There are 42 FAILs running the tests over ra_local, and fs-fs-pack-test
> appears to hang and needs to be killed.  I have not yet investigated any
> of these failures:
>
> FAIL:  cache-test 4: basic membuffer svn_cache test
> FAIL:  cache-test: Unknown test failure; see tests.log.
> FAIL:  fs-fs-pack-test 18: file with 0 expanded-length, issue #4554
> FAIL:  fs-fs-pack-test: Unknown test failure; see tests.log.
> FAIL:  fs-fs-private-test 3: load the P2L index
> FAIL:  fs-fs-private-test 1: get statistics on a FSFS filesystem
> FAIL:  fs-test 42: test svn_fs__compatible_version
> FAIL:  fs-test 66: test rep-sharing on content rather than SHA1
> FAIL:  op-depth-test 69: move/delete file externals (issue 4293)
> FAIL:  parse-diff-test 9: test parsing unidiffs lacking trailing eol
> FAIL:  ra-test: Unknown test failure; see tests.log.
> FAIL:  repos-test 7: test authz access control
> FAIL:  repos-test 10: test authz with global groups
> FAIL:  repos-test: Unknown test failure; see tests.log.
> FAIL:  utf-test 7: test svn_utf__fuzzy_escape
> FAIL:  copy_tests.py 4: svn cp URL URL cannot overwrite destination
> FAIL:  diff_tests.py 51: create a diff in git unidiff format for wc-wc
> FAIL:  diff_tests.py 52: create a diff in git unidiff format for url-wc
> FAIL:  diff_tests.py 53: create a diff in git unidiff format for url-url
> FAIL:  diff_tests.py 56: create a diff in git format for empty files
> FAIL:  diff_tests.py 57: create a diff in git format showing prop changes
> FAIL:  diff_tests.py 68: create a diff in git unidff format for wc dir mv
> FAIL:  externals_tests.py 44: move with file externals
> FAIL:  externals_tests.py 48: file externals unversioned obstruction
> FAIL:  patch_tests.py 13: patch target with no svn:eol-style
> FAIL:  patch_tests.py 15: patch target with uncommitted svn:eol-style
> FAIL:  patch_tests.py 20: apply the same patch twice
> FAIL:  patch_tests.py 21: patch with dir properties
> FAIL:  patch_tests.py 27: revert a patch by reverse patching
> FAIL:  patch_tests.py 32: patch file lacking trailing eol
> FAIL:  patch_tests.py 44: apply a patch to an empty file
> FAIL:  patch_tests.py 45: svn diff created patch should apply without fuz
> FAIL:  patch_tests.py 53: patch delete modified
> FAIL:  patch_tests.py 54: find closest hunk
> FAIL:  stat_tests.py 27: run 'status -u' with locally deleted directories
> FAIL:  svnadmin_tests.py 24: svnadmin verify with non-UTF-8 paths
> FAIL:  svnauthz_tests.py 8: test 'svnauthz accessof --is' on files
> FAIL:  svnauthz_tests.py 9: test 'svnauthz accessof --is' on files and urls
> FAIL:  svnfsfs_tests.py 1: load-index in a packed repo
> FAIL:  svnfsfs_tests.py 2: stats on empty repo shall not crash
> FAIL:  upgrade_tests.py 15: upgrade tree conflict data (f20->f21)
> FAIL:  upgrade_tests.py 21: upgrade from format 28: rename pristines
>
Reply | Threaded
Open this post in threaded view
|

Re: Reviewing 1.10 APIs & compatibility

Daniel Shahaf-2
Julian Foad wrote on Tue, 16 Jan 2018 13:09 +0000:
> Philip Martin wrote:
> >> Julian Foad wrote:
> >>> Another possible approach is to look for compatibility breakage by
> >>> running the 1.9 client and test suite against the 1.10 libraries,
> >>> and indeed different client/server version combinations.
> >
> > I did this recently.
>
> Thank you Philip! Extremely helpful.

Very much agreed!

We should do this before every minor release.  (Ideally we'd have a
buildbot task doing this, but until that happens, we should at least do
it manually before every minor release.)

I'll add the jira ticket / releasing.part.html bullet point later,
unless someone beats me to it...

Cheers,

Daniel