Daniel Shahaf <danielsh_at_apache.org> writes:
> 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).
I guess that would be implemented by a non-blocking attempt to get a
lock. Occasionally it would see a commit holding a lock as well as the
other longer running commands. I can't decide whether queries like
that, or the freeze query, are useful.
>> 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.
At present a failed exec returns 255 (on my machine). The problem is
that the external program can also return 255. If we document a value
then callers know it is possible that exec failed but can't be sure.
It doesn't just have to be exec that fails. The freeze could fail to
get a lock due to OS permissions or incorrect repository path. The
freeze could timeout if we add a timeout feature. We could document a
whole series of different errors but all are ambiguous when the program
errors are considered. The only thing the caller can rely on is
success/failure.
>> Write it to standard output in some known form?
>
> Couldn't the freeze command have printed arbitrary stuff to stdout and stderr?
That's why I think there is no easy solution.
>> Invoke some post-freeze command and pass it as a parameter?
>
> I suppose the post-freeze command should be optional?
I think so but I'm not sure how, or even if, it would work. Would we
simply have the the same problem of how to return the post-freeze
command status?
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Received on 2013-05-31 15:24:11 CEST