You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Johannes Graumann <jo...@web.de> on 2010/03/24 08:43:28 UTC
svn-fast-backup: return value differentiation between serious failure and existing revision?
Hi,
I'm scripting the nightly backup of my subversion repositories via 'svn-
fast-backup'. I started out summing up the return values of all invocations
in the script, intending to trigger an email if the sum is != 0, which means
I would have to have a closer look. This strategy is problematic though, as
'svn-fast-backup' also returns 1 if the repository wasn't modified since the
last backup and 'svn-fast-backup' exits with the message that the last
existing revision is already backuped - which is not a "real" problem at
all.
Can anyone point out a strategy on how to distinguish whether 'svn-fast-
backup' shut down for this benign reason or for something serious?
Thanks for any hints, Joh
Re: svn-fast-backup: return value differentiation between serious
failure and existing revision?
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Mar 24, 2010 at 09:43:28AM +0100, Johannes Graumann wrote:
> Hi,
>
> I'm scripting the nightly backup of my subversion repositories via 'svn-
> fast-backup'. I started out summing up the return values of all invocations
> in the script, intending to trigger an email if the sum is != 0, which means
> I would have to have a closer look. This strategy is problematic though, as
> 'svn-fast-backup' also returns 1 if the repository wasn't modified since the
> last backup and 'svn-fast-backup' exits with the message that the last
> existing revision is already backuped - which is not a "real" problem at
> all.
> Can anyone point out a strategy on how to distinguish whether 'svn-fast-
> backup' shut down for this benign reason or for something serious?
Sounds like a misfeature/bug of that script.
Can you submit a patch that makes exit 0 even if the repository
hasn't changed since? I guess doing that is the best solution.
If that is not an option, a scheme like the following should work:
exit 0 -> everything fine
exit 1 -> repository hasn't changed since last run
exit anything greater 1 -> a real error has happened
Thanks,
Stefan