On 27.11.2017 12:41, Evgeny Kotkov wrote:
[Changing subject, as apparently the test failures are not connected to
  the discussed fix for the rep sharing and issues #4623, #4700]

Stefan Fuhrmann <stef...@apache.org> writes:

Test expectations may need to be adapted.
With v7 repos (see r1816402), I get two
test failures while v4 and v6 pass:

[...]

FAIL:  svnadmin_tests.py 12: svnadmin verify detects corruption dump can't

[...]

FAIL:  svnadmin_tests.py 24: svnadmin verify with non-UTF-8 paths

I committed two follow-ups to the addition of precooked v7 repositories
in r1816402:

     https://svn.apache.org/r1816424
     https://svn.apache.org/r1816425

The first of these follow-ups limits the mentioned svnadmin tests to only
run with precooked repositories of formats 4 and 6 — as these tests perform
a set of hardcoded manipulations, assuming that the repository does not
use logical addressing.

Thanks.

Speaking of the added precooked repositories of formats 1-3, I am not too
sure if they should be created with the 1.9 binaries, as stated in the log
message for r1816402.  I think that the actual repositories created with
older SVN versions may be different from the ones created with the
`--compatible=version=` option, and that using the latter approach may
just create a false sense of security.

Perhaps, an alternative way would be to find the 1.1 binaries, prepare the
precooked format 1 repositories using it and limit the set of precooked
repositories to v1, v4, v6 and v7.

It took some manual intervention but I was able to build 1.1
and friends on my workstation and re-created the template repos
with those. They actually are different, in particular their
fsfs.conf and the presence of some files is not the same as
with later releases.

     https://svn.apache.org/r1816944

(Also, I think that the main.py:parse_options() function may need an update
  to properly handle the added v1-v3 precooked repositories by downgrading
  the server_minor_version — as otherwise, the various test suite checks such
  as server_has_mergeinfo() won't kick in.)

As of r1816965, that's fixed.  There is still things that will
fail for v1-v3 but these should not be too hard to fix in the
near future.

-- Stefan^2.

Reply via email to