On Thu, Aug 9, 2012 at 12:51 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> On Thu, Aug 9, 2012 at 10:06 AM, Philip Martin
> <philip.martin_at_wandisco.com> wrote:
>> The freeze-lock is similar to a write-lock: it exists for the duration
>> of the process that creates it. For scripts my trial freeze-program has
>> an interface like:
>>
>> freeze-program repo [repo ...] -c command [arg ...]
>>
>> which freezes a number of repositories and then runs the given command.
>> When the freeze-program exits the repositories are unfrozen.
I'd think a process like this would be more desirable:
freeze && backup
unfreeze
If you put the repo on something like a Netapp you may want to use its
snapshot features which would be on a different machine (meaning you'd
end up having to give your repo machine access to run the snapshots in
order to do the propossed -c style process).
You could certainly do this:
freeze -c 'somescript that waits forever' &
backup
kill the script that's waiting forever.
But that looks really ugly.
> What does a frozen repository actually look like for clients? I assume
> only write operations are affected. What happens to a commit or a
> propset or a revprop change?
Ignoring how it actually behaves right now I'd imagine that the
desired behavior here ought to be some reasonable wait on the server
side for the lock to be freed (in most cases the snapshot should
happen very quickly) and then proceed with the write activity if the
timeout isn't reached. If it is obviously you'd need to return an
error to the client.
Received on 2012-08-10 00:23:49 CEST