On Fri, Jun 25, 2010 at 7:10 PM, Philip Martin
<philip.martin_at_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
Received on 2010-06-26 12:08:32 CEST