Daniel Shahaf <danie...@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
