Greg Hudson wrote:
> On Fri, 2005-08-19 at 09:47 +0100, Max Bowsher wrote:
>> Something has just occurred to me. Without any repository wide shared
>> lock,
>> we have no way of locking a repository for mandatory single-threaded
>> operations.... such as recovery (bdb only) AND in-place format upgrade
>> (*applies to FSFS too*)!
>
> It is my belief that readers of an FSFS repository should not do any
> locking and should require nothing more than read access, and we should
> design around that constraint.
>
> If that means automatic in-place format upgrades are very difficult, I
> don't think we should compromise the principle. I don't think we should
> be making changes in the 1.x line which require in-place format upgrades
> anyway. (What if an automated upgrade is interrupted halfway through?
> A borked working copy is one thing; a borked repository is
> catastrophic.)
We did an upgrade for "svn lock" locking, but that was OK, because the
totality of the upgrade was a single "mkdir".
The design goals you state above make a lot of sense, and we can support
them easily enough by forcing all non-trivial upgrading to be via dump/load.
So.... I think my original patch is OK, and if no objections, I will include
it in the Cygwin binary package of 1.2.3 that I will be producing shortly.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Aug 20 22:55:01 2005