[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: Daniel Shahaf <danielsh_at_apache.org>
Date: Fri, 31 May 2013 12:49:07 +0000

On Fri, May 31, 2013 at 01:35:57PM +0100, Philip Martin wrote:
> 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?

For what it's worth:

I wanted to add "Is a write-lock being held?" to 'svnadmin info'. That was
just on a hunch that it might be useful --- I didn't have a concrete use-case
(and that feature has not been implemented).

> 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?

IIRC, some applications use the following strategy: "If execvp() failed,
exit 126; else, exit with the child's exit code (possibly zero)".

Sorry, I don't remember which man page I saw that strategy in.

> Write it to standard output in some known form?

Couldn't the freeze command have printed arbitrary stuff to stdout and stderr?

> Invoke some post-freeze command and pass it as a parameter?

I suppose the post-freeze command should be optional?
Received on 2013-05-31 14:49:16 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.