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