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.
I see. Makes sense. Will it also work for the sqlite lock? (you mentioned that you would like to lock repcache.db as well). > 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. -- Stefan^2. -- Join us this October for Subversion Live 2012 – 2 full days of training, networking, live demos and more! 25% off before Aug. 10th with discount code “earlybird.” Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
