On Thu, Aug 9, 2012 at 10:06 AM, Philip Martin <philip.mar...@wandisco.com> wrote: > Stefan Fuhrmann <stefan.fuhrm...@wandisco.com> writes: > >> On Wed, Aug 8, 2012 at 4:57 PM, Mark Moe <markmo...@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
