Justin Erenkrantz <justin@erenkrantz.com> writes:
> Am I right that you now intend to revert r13384 as well?
No. Some or all of r13384 would be reverted if we decided to do the
explicit 'svnadmin upgrade' thing, but I do not intend to do that
unless we have a consensus on it here.
> 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.
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.
> 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.
The idea is that the error messages would clearly state that someone
needs to run 'svnadmin upgrade' on the repository.
> > (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.
Yes, this was my primary argument to Max.
> > 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. --
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
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?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 12 18:55:59 2005