[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: When to upgrade repository format number?

From: <kfogel_at_collab.net>
Date: 2005-03-12 19:11:41 CET

Justin Erenkrantz <justin@erenkrantz.com> writes:
> 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.

I think r13366 was seductive, but ultimately not the best way to go.
As Mike Pilato points out, some of the svn_fs functions still
(unavoidably) bypass the repository format check, so it's not
foolproof. Furthermore, the locking tables/directories and the
locking hooks are created unconditionally the first time 1.2 uses a
legacy repository. If we don't also upgrade the format number, the
repository would then be in a weird in-between state, at least to
anyone who bothered to look closely.

This would be hard to keep track of and hard to explain. It also
would be likely to confuse us months from now, when we're debugging
some repository, and have forgotten all about our complex upgrade
strategy!

This is a time to remember "KISS", in my opinion :-).

Also: FWIW, it turns out that Mike Pilato and Ben Collins-Sussman had
persuaded me of all this before I committed r13366, I just forgot
about the conversation. *And* I mistakenly thought that the r13366
plan represented some sort of list consensus, when it actually was
just a spur-of-the-moment idea that a few people had in IRC (and most
of those people were Mike and Ben, who had not yet recanted). So if
we were to revert r13384 and go back to r13366, it would run counter
to what I perceive to be the majority preference right now.

My preference right now is to leave r13384 as it is, and put a
prominent warning in the release notes, which admins ought to be
reading anyway. We can, if it ever becomes an issue, easily provide a
'downgrade' script, but I doubt there will be much demand.

> > 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

I'm not planning to do this unless we have widespread agreement on it.
As you can tell, I'm only half-persuaded myself.

-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 19:32:51 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.