Daniel Shahaf wrote:
> Philip Martin wrote on Fri, May 31, 2013 at 14:23:35 +0100:
>> 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?
>>>
>>> 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.
Just an opinion from general experience in the world of computers. With any system where some resource is reserved (locked), it can be useful to find out who/what has the lock. So, a system that tells me the repo is currently locked by which of the following:
commit
pack
freeze
...
would be useful, in my opinion. An output that enumerates one of the above list would be useful.
Even better would be an additional output that identifies more specifically which server process or remote process holds the lock (PID, some sort of URL, and/or whatever means of identifying it may be available, if any). This might or might not be uniform enough to be useful as an API, but would certainly be useful for a human admin to look at.
But whether it's worth implementing this amount of detail at this point in time... I don't know.
>>>> 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)".
>>
>> 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.
>
> Can't we just ask people who really care about all 8 bits of the child's
> exit code to use the bindings?
Yes -- it's very rare to need to know all possible exit statuses from the child, and in such a case the admin can write a wrapper for the program (that puts the exit code somewhere else) or use the bindings.
Solve the 99% case simply by defining a mapping of exit codes in some lossy way such as:
PROG -> freeze
0 -> 0
1 -> 1
2 -> 2
...
99 -> 99
100..255 -> 100
-- 101..126 'freeze' errors:
-- 101 timeout getting the lock
-- 102 other failure to get the lock
-- 103..125 reserved
-- 126 failed to execute the freeze PROG
-- 255 'svnadmin' itself didn't exist
or whatever.
- Julian
>
>> >> 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?
>
> We'd have the failure mode that the freeze-hook failed to run (or ran
> and exited non-zero). Callers also have to handle the failure mode
> whereby 'svnadmin' itself didn't exist (which goes back to your
> "failed
> exec reports 255" above).
>
Received on 2013-05-31 16:37:41 CEST