Do SHA1 pristines need a wc format bump?

[Philip Martin <ph...@wandisco.com>]

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

Re: Do SHA1 pristines need a wc format bump?

[Greg Stein <gs...@gmail.com>]

On Fri, Jun 25, 2010 at 14:21, Philip Martin <ph...@wandisco.com> wrote:
> Greg Stein <gs...@gmail.com> writes:
>
>> If in-db props are needed for pristine, then I don't think swapping
>> their format numbers makes sense.
>
> No, in-db-props are not needed for pristine.

Oh! For some reason, I thought it did.

If you're ready to go, then by all means...

I've got some coding time this weekend to do the upgrade tests, and
then next week I'm home. So you can quick do it, or see where I am by
Monday. There may be an argument for just doing both as part of format
17. The in-db props exposure is limited, as I mentioned.

Cheers,
-g

Re: Do SHA1 pristines need a wc format bump?

[Philip Martin <ph...@wandisco.com>]

Greg Stein <gs...@gmail.com> writes:

> If in-db props are needed for pristine, then I don't think swapping
> their format numbers makes sense.

No, in-db-props are not needed for pristine.

-- 
Philip

Re: Do SHA1 pristines need a wc format bump?

[Greg Stein <gs...@gmail.com>]

If in-db props are needed for pristine, then I don't think swapping
their format numbers makes sense.

My only delay in performing the bump for in-db props is testing the
upgrade code. We can cross our fingers, do the bump, and post-bump
complete the upgrade testing. (the exposure would only be limited to
people who run 'svn upgrade' and any devs who are using f16 right now)

Cheers,
-g

On Fri, Jun 25, 2010 at 14:10, Philip Martin <ph...@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.
>
> 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
>

Re: Do SHA1 pristines need a wc format bump?

["Hyrum K. Wright" <hy...@mail.utexas.edu>]

On Fri, Jun 25, 2010 at 7:10 PM, Philip Martin
<ph...@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