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...@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).
