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

Re: locking a file renders repos unusable with older clients

From: Branko Čibej <brane_at_xbc.nu>
Date: 2005-03-30 15:51:52 CEST

Tobias Ringström wrote:

> Ben Collins-Sussman wrote:
>> On Mar 28, 2005, at 5:07 PM, C. Michael Pilato wrote:
>>> Question: How much do we care about repository sanity during this
>>> upgrade? I started to code these new APIs, but couldn't decide if I
>>> needed to reproduce the whole 'exclusive lock' code ala
>>> svn_repos_recover2(), and, if so, how to deal with the same scenario
>>> down in the svn_fs libraries (which, in theory, could be upgraded
>>> independently of the svn_repos wrapper).
>> I think that svn_repos_upgrade() should share the same "waiting for
>> exclusive repository lock" logic that svn_repos_recover() uses.
> It would be nice to be able to avoid the exclusive repository lock
> because it's quite disruptive, and it makes it harder to upgrade busy
> repositories online.
> My knowledge of the details of the locking implementation is a little
> fuzzy, but it is my understanding that the upgrade only adds new
> files/DBs (i.e. does not modify existing ones) and changes the format
> file. If so, how about creating the new locking files/DBs and then, as
> a last step, move a new format file in place of the old one to
> atomically upgrade the repository. If we care about the risk of two
> simultaneous upgrades (which I think we should), it should be possible
> to create a write lock on the format file before starting the upgrade.

Creating those new tables should take close to no time at all. I doubt
there's a repository that's so busy that you can't afford to lock it for
one second.

-- Brane

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 30 15:55:26 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.