On Fri, Jun 25, 2010 at 7:10 PM, Philip Martin <philip.mar...@wandisco.com> wrote: > 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.
The upgrade code for pristines may not be complete, and isn't very well tested. I had some conversations with Greg about it at the Hackathon, but haven't followed up. Greg can correct me, but I believe the core idea was that instead of just grabbing anything in the current text-base directory (which is what we currently do), we should be looking at the db, and only migrating test-bases which are actually used. I believe the alternative would be to use the current method, and then "scrub" the pristines according to what is in the db. -Hyrum
