On Thu, Aug 9, 2012 at 10:06 AM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> writes:
>
>> On Wed, Aug 8, 2012 at 4:57 PM, Mark Moe <markmoe19_at_gmail.com> wrote:
>>> This would be useful for our us too. I would add "freeze" to the start and
>>> "unfreeze" to the end of the script we use to rsync a copy of our repo (and
>>> associated files) to an off-site network share.
>>
>> If freeze and unfreeze can be used quasi-independently,
>> there should be a way to "recover" (unfreeze) the FSFS
>> repo if the script using the new API failed.
>>
>> Maybe pass some string token to "freeze" and have an
>> API to read that token (returning NULL for non-frozen
>> repos). Some user-specific watchdog / recovery logic
>> may then decide whether to call unfreeze or not.
>
> 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.
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?
What's the difference with changing your pre-commit hook temporarily
to "exit 1"?
--
Johan
Received on 2012-08-09 21:51:58 CEST