Ben Reser <b...@reser.org> writes: > On Thu, Aug 9, 2012 at 12:51 PM, Johan Corveleyn <jcor...@gmail.com> wrote: >> On Thu, Aug 9, 2012 at 10:06 AM, Philip Martin >> <philip.mar...@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
I don't know how that would be implemented--I think it would need a new repository format with some new locking mechanism. My proposal is simply to take the existing write-locks which don't persist beyond the process lifetime. >> 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? Anything that attempts to write will block either until the freeze is over or some timeout occurs depending on how the writer has been designed. For a live repository with commits going on the command freeze-program repository -c command causes attempts to take new write-locks to block, waits until existing write-locks are released, and then runs the command with the repository frozen. When the command finishes the freeze-program exits which unfreezes the repository thus allowing the blocked write-locks to proceed. -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
