Do SHA1 pristines need a wc format bump?

Compiling with SVN_EXPERIMENTAL_PRISTINE causes pristine text to be
stored in .svn/pristine/ using SHA1 filenames instead of
.svn/text-base/ using filenames derived from the working file. It's
nearly complete enough to pass the regression test, I'm down to 4
FAILs at present.

I've reached the stage where I need to teach the regression test to
find pristine text in the new locations, and the problem is that the
testsuite doesn't know whether to look for the old or the new name. I
can hack it by having SVN_EXPERIMENTAL_PRISTINE no longer create the
text-base directory, and use that to indicate which file to expect.
However I think this is an indication that the wc format needs to be
bumped. Essentially you cannot mix clients built with and without
SVN_EXPERIMENTAL_PRISTINE, neither handles the others working copy.

There is already some upgrade code for SHA1 pristines, but it assumes
that the in-db-props upgrade happens first. So, I'm thinking of
switching those two and making format 17 the one that enables SHA1
pristines, leaving in-db-props to format 18. Initially this would
still be conditional on SVN_EXPERIMENTAL_PRISTINE, so in the short
term people would continue to use format 16.

One problem is that we probably can't fix all the
SVN_EXPERIMENTAL_PRISTINE FAILs until the NODE_DATA 4'th tree appears.
If that means we want to delay removing the SVN_EXPERIMENTAL_PRISTINE
conditional, we run in to the problem that in-db-props might want to
start using format 17 first. It's not a big problem, we can assume
that anyone who uses SVN_EXPERIMENTAL_PRISTINE realises that the
format upgrade might not be stable.

-- 
Philip