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

Re: Locking: repos upgrades?

From: Branko Čibej <brane_at_xbc.nu>
Date: 2004-11-20 13:15:19 CET

Erik Huelsmann wrote:

>On Sat, 20 Nov 2004 00:27:19 -0500, Greg Hudson <ghudson@mit.edu> wrote:
>
>
>>On Fri, 2004-11-19 at 22:20, Garrett Rooney wrote:
>>
>>
>>> Otherwise it seems like we can never bump a repository or working copy
>>>format in 1.x, which seems kind of extreme to me.
>>>
>>>
>>I think the language is pretty clear that we're allowed to bump the
>>repository format during a 1.x series, but that doesn't mean it's a good
>>idea.
>>
>>We know that forcing a dump and load for a downgrade will cause pain in
>>some number of situations, including some situations where people never
>>even considered using locking. Unless we think it's really bad if a
>>lock is circumvented because someone accessed the repository with 1.1
>>server code, I think we should leave the version alone.
>>
>>
>
>Well, yes, I think it is bad that people can use different binaries
>against the repository and circumvent the locks.
>
>With respect to downgrading the repository: I don't think the other
>tables change their layout (are they allowed to?), meaning that an
>upgrade will consist of:
>
>- <create new tables>
>- echo 4 > format
>
>Then can't we provide a downgrade script to do the reverse? No
>dump/load will be necessary, just as we promised. (This should make it
>into the faq even before it is implemented, I guess.)
>
>
I was going to suggest something like this, too. It's a bad idea to
require a dump/load to downgrade, but it's also a bad idea to allow a
/silent/ downgrade. So it's better to bump the format number and tell
people to change it back (or proide a script to do so) if they want to
downgrade. Bumping the format number will also prevent unintentional use
of older (say, statically linked) binaries with a new repository.

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 20 13:16:30 2004

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