On Thu, Aug 23, 2012 at 12:26 AM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> Johan Corveleyn <jcorvel_at_gmail.com> writes:
>
>> Ok, let me try to decipher what that means for users.
>>
>> - New commit will block: does this mean that 'svn commit -mm somefile'
>> will simply hang (until the repository is unfrozen, or until the
>> client-side timeout is reached)? Can it be cancelled?
>>
>> - Commit in progress will block when trying to convert the transaction
>> into a revision: so the running 'svn commit -mm somefile' will hang at
>> the end (after transmitting file contents, but before the "Committed
>> Revision XXX" notification), until the repository is unfrozen, or
>> until the client-side timeout is reached, right? Can it be cancelled?
>> What happens if I cancel, or if the client-side timeout is reached
>> (will the repository still commit the transaction when it's unfrozen;
>> will my working copy still be ok)?
>>
>>> I'm currently using BDB's svn_repos lock for the BDB freeze so that
>>> makes a BDB repository completely unreadable while frozen. No BDB
>>> commits can start while frozen. Starting a BDB freeze has to wait for
>>> in-progress commits to finish.
>>
>> Does that mean that a new 'svn commit -mm somefile' will error out? Or
>> will it hang until unfrozen or until client-side timeout?
>>
>> Wouldn't we want the same behavior, at least for the end-user,
>> regardless of BDB or FSFS (or other backends)?
>>
>> If all of this is not really decided yet, what is the intention? Is
>> this still under discussion? Shouldn't we decide on the desired
>> behavior before the feature is implemented?
>
> I haven't changed how we block on the write-lock: the block doesn't
> timeout it waits for the lock to be released. The client may timeout
> waiting for the RA layer.
Okay, but isn't this a little different from one in-progress-commit
blocking another? This is an explicit administrative action. A
repository can be frozen for a long time (unless we advertise the
feature very, very clearly as "the repository must only be frozen for
a short time ... do not initiate long running tasks while the
repository is frozen, ...").
> If we want to introduce some new "freeze lock" with different behaviour
> from the write-lock then we would need to bump the repository format as
> old releases simply would not look at any new lock.
>
> I suppose we could change how 1.8 blocks on the write-locks but we
> obviously can't change existing releases.
I'm not sure how this should be handled. I am mainly trying to
understand it all right now, trying to see what this would mean for me
as an administrator. I'm sure other administrators will have similar
questions, so at the very least I'm preparing for answering users-list
questions :-) ...
And I'm a bit worried that this (IMO important) aspect of the feature
hasn't been discussed before it was implemented.
--
Johan
Received on 2012-08-23 01:10:00 CEST