You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@apache.org> on 2018/01/08 10:36:46 UTC
Re: Reviewing 1.10 APIs & compatibility
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
Re: Reviewing 1.10 APIs & compatibility
Posted by Julian Foad <ju...@apache.org>.
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
Re: Reviewing 1.10 APIs & compatibility
Posted by Philip Martin <ph...@codematters.co.uk>.
Julian Foad <ju...@apache.org> writes:
> Philip Martin wrote:
>> First I ran the 1.9 testsuite against 1.10 servers
>> over http:// and svn://. [...]
>
> Philip, please can you tell me how you did this?
For http://
-----------
In the 1.9 build directory first run 1.9 davautocheck.sh:
APACHE_MPM=event .../subversion/tests/cmdline/davautocheck.sh --no-tests
which creates an apache configuration in:
subversion/tests/cmdline/httpd-2018-xxxxxx/
and starts a server. Kill the server either with ps/kill or:
/usr/sbin/apache2 -f `pwd`/subversion/tests/cmdline/httpd-2018*/cfg -k stop
Now edit the apache configuration file:
vi subversion/tests/cmdline/httpd-2018-xxxxxxx/cfg
and change the paths for the mod_dav_svn, mod_authz_svn and
mod_dontdothat modules to refer to your 1.10 build. Start the server:
/usr/sbin/apache2 -f `pwd`/subversion/tests/cmdline/httpd-2018*/cfg -k start
and run the 1.9 tests:
make check CLEANUP=1 PARALLEL=1 BASE_URL=http://localhost:3691
To verify that apache is really using the 1.10 libraries use ps to get
the ID of one of the apache processes and then run:
grep libsvn /proc/NNN/maps
For svn://
----------
In the 1.10 build directory run:
subversion/svnserve/svnserve -Tdr .../1.9-build/subversion/tests/cmdline
then in the 1.9 build directory run:
make check CLEANUP=1 PARALLEL=1 BASE_URL=svn://localhost
Running the 1.10 tests against a 1.9 apache/svnserve is much the same
except that you need to specify SERVER_MINOR_VERSION when invoking make
check.
--
Philip
Re: Reviewing 1.10 APIs & compatibility
Posted by Julian Foad <ju...@apache.org>.
Philip Martin wrote:
> Julian Foad <ju...@apache.org> writes:
>> Philip Martin wrote:
>>> First I ran the 1.9 testsuite against 1.10 servers
>>> over http:// and svn://. [...]
>>
>> Philip, please can you tell me how you did this?
>>
>> [...]
>>> 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.
>> [...]
>
> Perhaps I answered the wrong question. If you are asking how I disabled
> part of ra-test then I simply removed the code and recompiled. Looking
> at it again I'm not sure why I referred to test 10 as the problem code
> is in get_dir_test()
I meant how you tested 1.9 against 1.10 and 1.10 against 1.9 in general.
Thanks for your first reply about that. This additional info is also useful.
- Julian
> Index: ../src-1.10/subversion/tests/libsvn_ra/ra-test.c
> ===================================================================
> --- ../src-1.10/subversion/tests/libsvn_ra/ra-test.c (revision 1823419)
> +++ ../src-1.10/subversion/tests/libsvn_ra/ra-test.c (working copy)
> @@ -604,6 +604,7 @@ get_dir_test(const svn_test_opts_t *opts,
> SVN_DIRENT_KIND, pool),
> SVN_ERR_FS_NOT_FOUND);
>
> +#if 0
> /* Test fetching SVN_DIRENT_SIZE without SVN_DIRENT_KIND. */
> SVN_ERR(svn_ra_get_dir2(session, &dirents, NULL, NULL, "", 1,
> SVN_DIRENT_SIZE, pool));
> @@ -611,7 +612,6 @@ get_dir_test(const svn_test_opts_t *opts,
> ent = svn_hash_gets(dirents, "A");
> SVN_TEST_ASSERT(ent);
>
> -#if 0
> /* ra_serf has returns SVN_INVALID_SIZE instead of documented zero for
> * for directories. */
> SVN_TEST_INT_ASSERT(ent->size, 0);
>
Re: Reviewing 1.10 APIs & compatibility
Posted by Philip Martin <ph...@codematters.co.uk>.
Julian Foad <ju...@apache.org> writes:
> Philip Martin wrote:
>> First I ran the 1.9 testsuite against 1.10 servers
>> over http:// and svn://. [...]
>
> Philip, please can you tell me how you did this?
>
> [...]
>> 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.
> [...]
Perhaps I answered the wrong question. If you are asking how I disabled
part of ra-test then I simply removed the code and recompiled. Looking
at it again I'm not sure why I referred to test 10 as the problem code
is in get_dir_test()
Index: ../src-1.10/subversion/tests/libsvn_ra/ra-test.c
===================================================================
--- ../src-1.10/subversion/tests/libsvn_ra/ra-test.c (revision 1823419)
+++ ../src-1.10/subversion/tests/libsvn_ra/ra-test.c (working copy)
@@ -604,6 +604,7 @@ get_dir_test(const svn_test_opts_t *opts,
SVN_DIRENT_KIND, pool),
SVN_ERR_FS_NOT_FOUND);
+#if 0
/* Test fetching SVN_DIRENT_SIZE without SVN_DIRENT_KIND. */
SVN_ERR(svn_ra_get_dir2(session, &dirents, NULL, NULL, "", 1,
SVN_DIRENT_SIZE, pool));
@@ -611,7 +612,6 @@ get_dir_test(const svn_test_opts_t *opts,
ent = svn_hash_gets(dirents, "A");
SVN_TEST_ASSERT(ent);
-#if 0
/* ra_serf has returns SVN_INVALID_SIZE instead of documented zero for
* for directories. */
SVN_TEST_INT_ASSERT(ent->size, 0);
--
Philip
Re: Reviewing 1.10 APIs & compatibility
Posted by Julian Foad <ju...@apache.org>.
Philip Martin wrote:
> First I ran the 1.9 testsuite against 1.10 servers
> over http:// and svn://. [...]
Philip, please can you tell me how you did this?
[...]
> 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.
[...]
- Julian
Re: Reviewing 1.10 APIs & compatibility
Posted by Branko Čibej <br...@apache.org>.
On 06.02.2018 16:39, Julian Foad wrote:
> if sbox.repo_url.startswith("http") and svntest.main.options.server_minor_ver
Nope; there are predicate functions for that.
svntest.main.is_ra_type_dav() in this case.
There's no predicate for the actual server version though.
-- Brane
Re: Reviewing 1.10 APIs & compatibility
Posted by Julian Foad <ju...@apache.org>.
Philip Martin wrote:
> [...] I've looked at all the
> errors that mixed 1.9-1.10 testing showed and I don't think any of them
> are release critical.
That's good news indeed. Then compatibility testing is no longer
blocking the release.
> For this particular test, the locking error
> message, we might choose to backport a 1.9 client fix to improve the
> client-generated error message and such a backport might make any change
> to the trunk test redundant. It may even be better to leave the trunk
> test unchanged so that it fails with 1.9.7 but passes with some future
> 1.9.8.
Sounds reasonable.
- Julian
Re: Reviewing 1.10 APIs & compatibility
Posted by Philip Martin <ph...@codematters.co.uk>.
Julian Foad <ju...@apache.org> writes:
> It looks like the behaviour changes in 1.10 are intentional and Good.
>
> I think the test suite should be updated to accept the old error when
> the server is old, like this:
I suppose we could change the testsuite along these lines, but I don't
see it as something we have to do for 1.10. I've looked at all the
errors that mixed 1.9-1.10 testing showed and I don't think any of them
are release critical. For this particular test, the locking error
message, we might choose to backport a 1.9 client fix to improve the
client-generated error message and such a backport might make any change
to the trunk test redundant. It may even be better to leave the trunk
test unchanged so that it fails with 1.9.7 but passes with some future
1.9.8.
--
Philip
Re: Reviewing 1.10 APIs & compatibility
Posted by Julian Foad <ju...@apache.org>.
I have requested a bit of work time to look at these issues.
Here's where I've got to with the first test failure.
Philip Martin wrote:
> 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.
It looks like the behaviour changes in 1.10 are intentional and Good.
I think the test suite should be updated to accept the old error when
the server is old, like this:
[[[
Index: subversion/tests/cmdline/lock_tests.py
===================================================================
--- subversion/tests/cmdline/lock_tests.py (revision 1823283)
+++ subversion/tests/cmdline/lock_tests.py (working copy)
@@ -1360,8 +1360,11 @@ def unlocked_lock_of_other_user(sbox):
svntest.actions.run_and_verify_status(wc_dir, expected_status)
# now try to unlock with user jconstant, should fail but exit 0.
- expected_err = "svn: warning: W160039: User '%s' is trying to use a lock owned by "\
- "'%s'.*" % (svntest.main.wc_author2, svntest.main.wc_author)
+ if sbox.repo_url.startswith("http") and svntest.main.options.server_minor_version <= 9:
+ expected_err = "svn: warning: W160039: .*[Uu]nlock of .*403 Forbidden.*"
+ else:
+ expected_err = "svn: warning: W160039: User '%s' is trying to use a lock owned by "\
+ "'%s'.*" % (svntest.main.wc_author2, svntest.main.wc_author)
svntest.actions.run_and_verify_svn([], expected_err,
'unlock',
'--username', svntest.main.wc_author2,
]]]
This is similar to what was present before r1716450, when the '403'
message was expected for the 'http' URLs, and the better message was
used for the svn:// case, which in 1.10 is now used for all cases.
However, this doesn't match the message Philip showed above, and this
is only for test #34.
I am still working on setting up the cross-version testing to pursue this.
- Julian
Re: Reviewing 1.10 APIs & compatibility
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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
Re: Reviewing 1.10 APIs & compatibility
Posted by Julian Foad <ju...@apache.org>.
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
>
Re: Reviewing 1.10 APIs & compatibility
Posted by Philip Martin <ph...@codematters.co.uk>.
Julian Foad <ju...@apache.org> 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