--On Saturday, March 12, 2005 11:33 AM -0600 kfogel@collab.net wrote:
> The issue is not the upgrade-the-repository step. That's easy. The
> issue is that it then becomes a problem if one *downgrades* one's
> server code after the repositories have been upgraded. The repository
> could continue to work, but lock information would be ignored and
> might get slowly out of sync.
How so? The format file should be guarding the previous minor releases from
even opening format 4 repositories. If not, that's a serious bug.
> The idea is that the error messages would clearly state that someone
> needs to run 'svnadmin upgrade' on the repository.
And, my belief is that this error message will only come well after the admin
has upgraded to 1.2. The admin may not care a whit about locking or how the
users use the repository. So, now everything will work for a few days and
then all of a sudden the admin will get confused emails from their users that
they now need to run another command (that we've never had before!) to enable
a feature that in all respects they could have legitimately thought they
enabled when they installed 1.2. AFAIK, there will be no way for the users
(or rather the svn clients) to know whether it has locking enabled at the FS
level or not...
This just makes the upgrade path for 1.2 way more complicated than it needs to
be. I'm not aware of many systems that require explicit upgrade commands
after installing new versions. FWIW, BDB and Bugzilla (and I'm sure others)
do auto-upgrades. (Yes, I'm sure that some require explicit commands too.)
> I'll try to explain it more clearly:
>
> 1. You create repository R with Subversion 1.1.
>
> 2. 1.2 is released, you upgrade your server code.
>
> 3. You use the new server to access R, R gets auto-upgraded to format 4.
>
> 4. Now you downgrade the server code to 1.1 (for whatever reason)
>
> 5. Your repository doesn't work with 1.1 anymore, even though you've
> never used any of the locking features.
>
> (You could tweak the scenario so that R was created with 1.2 and then
> later you downgrade the server, still never having used the locking
> code. It wouldn't make much difference to the problem.)
>
> It is *permissible* for this non-downgradeable incompatibility to
> exist, no one argues with that. The question is, is it the best
> thing? Some sites will never use the locking features; for those
> repositories, upgrading to format 4 is a purely harmful move. It
> makes them unable to downgrade the server code later, yet brings them
> no benefits
Which is why the original commit to delay the format 4 upgrade until it is
required still makes a lot of sense. We try and be nice as long as we
possibly can, but once the users start performing locking operations - in
order to maintain consistency - we need to automatically bump the format.
> Max's point was that it might be better to make the enabling of
> locking (and thus the upgrading to format 4) an explicit event, where
> the admin demonstrates consciousness that they are taking the
> repository to a new, incompatible format. To force this, the locking
> operations would insist on a format 4 repository. (We could have
> another 'svnadmin downgrade' command pretty easily, but that's not an
> integral part of this proposal.)
>
> I'm not sure any of this is worth the extra complexity to explain to
> users (let alone to explain on the dev@ list!). But now do you
> understand the concern, and the proposed solution?
I understand it. I strongly disagree with it. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 12 19:13:03 2005