--On Friday, March 11, 2005 5:03 PM -0600 kfogel@collab.net wrote:
> Remain at repository format 3 by default. After upgrading to 1.2, the
> code would not demand format 4, until you use locking features.
> Before you use them, you must run
>
> $ svnadmin upgrade REPOS
>
> This would be the moment when your repository becomes incompatible
> with pre-1.2 Subversion. In other words, we'd remain compatible by
> default, and insist that the admin do something exceptional to enable
> locking, so that admins can't miss the fact that this is an one-way
> step.
Am I right that you now intend to revert r13384 as well?
I really think making the upgrade path be explicit is going to bite us in the
butt. Admins will not understand this or read the documentation. The users
are the ones who will be driving locking, not the admins.
Are we doing incompatible schema changes? I thought we were just adding new
tables? Why can't we continue to do a silent upgrade? IIRC, we've done this
in the past when we're not doing incompatible changes.
So, no, I don't think mandating an explicit step to 'upgrade' repositories is
sound behavior on our parts. No one will read the instructions and will be
complaining when locking doesn't work.
> (Internally, the locking functions would all check that the repository
> format was 4 or higher, and error if not.)
>
> After arguing with Max for a while, I now think this is a sane
> proposal, and maybe even our best option.
>
> Some unanswered questions:
>
> * Would 'svnadmin create' create format 4 or format 3 repositories
> in 1.2?
It'd have to be 4. There is no excuse for making the admin do two steps to
activate locking or pass special flags. Subversion 1.2 should support locking
out-of-the-box for new repositories.
> * If format 3, would 'svnadmin create' take a new option to
> indicate that you want locking from the beginning?
>
> * If format 3, would we move the silent auto-creation of the
> locking tables/hooks/etc to become part of 'svnadmin upgrade',
> instead of part of the default 1.2 code as they are now?
The pre-condition fails to these questions. =)
> One possible response is: "This is nice, but too complex. Let's just
> unconditionally upgrade repositories to 4, and create new ones at 4.
> Admins should be reading the release notes carefully anyway!"
>
> If that's the way we want to go, then we don't have to do anything,
> because that's how the current code behaves.
>
> Finally, note that our compatibility guidelines permit both ways.
Our compatibility guidelines maintain that a format 3 repository must be read
by all 1.x series servers. We can't mandate a dump/load until 2.0. But, I
just don't understand what the drawback is here. -- 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 00:38:45 2005