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