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