[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Using "svnadmin freeze"

From: Doug Robinson <doug.robinson_at_wandisco.com>
Date: Fri, 31 May 2013 10:34:36 -0400


How do I subscribe to the dev list? Not sure I really have time for
that... but perhaps.

Thank you.


On Fri, May 31, 2013 at 9:03 AM, Philip Martin

> Doug,
> I started a thread on the dev list and meant to cc you but forgot.
> Don't feel any obligation to promote the ideas but do feel free to
> contibute if you want to.
> Philip Martin <philip_at_codematters.co.uk> writes:
> > One of my colleagues at WANdisco asked some questions about using
> > freeze. The first thing he wanted to know is how to detect whether a
> > freeze is running. There are various approaches: look at running
> > processes, look at processes with the lock file open, implement some
> > external lock, etc. but none are reliable or portable. The only
> > reliable way to do it is for Subversion to provide some sort of
> > implementation.
> >
> > A freeze query might be implemented by having a separate freeze lock.
> > The freeze function itself would then take the freeze lock before taking
> > the write lock, and the freeze query would try a non-blocking lock of
> > the freeze lock. This would probably go into the repos layer to avoid
> > duplicate implementations.
> >
> > I think something like that would work but I'm unsure whether we should
> > provide it. I'm concerned that it would be making freeze special.
> > Would we need to provide similar queries for upgrade, recover, pack,
> > etc?
> >
> > A second point was about adding a timeout to freeze. At present freeze
> > blocks until it gets the write lock and will wait as long as it takes.
> > There is no timeout in APR's file locking API so to implement a timeout
> > we would need to either sit in a loop attempting non-blocking locks or
> > use SIGALARM to cause EINTR. I think that would work but again I'm
> > unsure how useful this feature would be.
> >
> > A timeout leads on to a question was about error handling. At present
> > the return value of "svnadmin freeze repository program" is the return
> > value of the external program provided freeze managed to run the
> > program. If freeze failed to run the program for some reason then the
> > return value is generated by svnadmin directly. There is no way to
> > distinguish errors from 'program' from errors from 'svnadmin', they both
> > return values in the range 0-255. Success, zero, is unambiguous but any
> > error is difficult to interpret.
> >
> > I don't see any easy way round this. If we stop providing the 'program'
> > error as the return value how else do we provide it? Write it to
> > standard output in some known form? Invoke some post-freeze command and
> > pass it as a parameter?
> >
> > --
> > Philip
> >
> --
> Certified & Supported Apache Subversion Downloads:
> http://www.wandisco.com/subversion/download

Douglas B. Robinson | *Senior Product Manager*
WANdisco // *Non-Stop Data*
t. 925-396-1125
e. doug.robinson_at_wandisco.com
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
Received on 2013-05-31 18:52:56 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.