Branko Čibej wrote:
> Ben Collins-Sussman wrote:
>
>>
>> On Aug 18, 2005, at 6:03 PM, Max Bowsher wrote:
>>
>>>
>>> If not for compatibility, yes, that would be the way to do it, BUT
>>> there is a problem. The lockfile is located outside the db/
>>> directory, which is the the "fs" which is handled by libsvn_fs. In
>>> other words, a svn repository is a libsvn_fs FS nested within a
>>> libsvn_repos "repos", and it would be a violation of the layered
>>> design for the inner layer to assume things about the implementation
>>> of the outer layer.
>>
>> So why can't libsvn_fs_base create a new 'lockfile' inside repos/db/,
>> and start doing all the shared/exclusive locking on that? The
>> lockfile sitting outside repos/db/ won't be created at all for new
>> repositories, and will just bit-rot in older repositories.
This is the elegant solution which we would do if we didn't care about
compatibility...
> He has a point, though. If you access the repository with a 1.3
> mod_dav_svn and a 1.2 svnadmin at the same time, the locking won't work
> correctly (even if the repository format didn't change otherwise).
... and this is the reason why we cannot do it. Our compatibility promises
bind us.
> Can we forbid this according to our compatibility rules? I don't know...
> We'd certiainly have to bump the repository format version.
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*)!
Um.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 19 10:48:34 2005