Eric Johnson wrote on Wed, Sep 16, 2015 at 16:11:21 -0700:
> Hi Daniel,
>
> The exact logistics of handling an error are probably pretty
> straightforward. The underlying problem is that it is never a good
> idea to pipe the output of svnrdump directly into svnadmin load,
> because svnadmin cannot handle the failure unless the stream itself
> carries more information.
>
I understand that point; the other replies address it.
Cheers,
Daniel
> Eric
>
> > On Sep 16, 2015, at 3:52 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> >
> > Eric Johnson wrote on Wed, Sep 16, 2015 at 11:03:08 -0700:
> >> So if the dump of the last commit is incomplete, I an error code tells me,
> >> what, exactly? That I need to manually edit the stream that I just dumped
> >> into a file? That I should discard the whole dump, and start again?
> >
> > If you run dump and you get a non-zero exit code, then the output should
> > be regarded as potentially corrupted. In the specific case of
> > ECONNABORTED, you can probably trust that the receiver received a prefix
> > of what the sender sent (TCP promises that), and therefore, trust
> > everything _except_ the last revision loaded.
> >
> > You can detect ECONNABORTED by looking at the E123456 error code. System
> > error codes are mapped into that range. On unix the mapping is usually
> > the identity (e.g., errno�2 becomes E000002). On windows there's an
> > offset of 720000 (see APR_FROM_OS_ERROR). The Subversion-specific error
> > codes always have the same numeric values regardless of platform (that's
> > the APR_OS_START_USERERR range, E120000 through E620000).
Received on 2015-09-17 01:41:59 CEST