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
