Hi Bert, The files that made it into the dump file were complete. It is just that the last commit in the dump file didn't have all of the files it was supposed to have.
This may be a deliberate design of the dump file format, but it does mean that svnrdump is badly broken. Svnrdump should not be dumping a partial commit upon network failure! Eric On Sep 15, 2015, at 1:52 AM, "[email protected]" <[email protected]> wrote: In what way was the dump file incomplete? Was it broken halfway through a file? (That should have been caught via the checksums in the file). If a whole node edit is missing it is still a complete dumpfile and there is no way the current dump doesn’t know when a revision is done. (This allows editing the revisions in this format; as is sometimes done on migrations) Bert *From: *Eric Johnson *Sent: *dinsdag 15 september 2015 07:16 *To: *[email protected] *Subject: *Incomplete SVN dump files I'm in a situation where I'm dumping Subversion repositories from remote locations (using svnrdump). The repositories are big enough, and the network connections between destinations just unstable enough that the repositories aren't making it all in one dump call. I've noticed, for one repository in particular, that I actually got a dump file that had only a part of the last commit before the connection broke. When I loaded up the repository, Subversion reported no problems on the svnadmin load, but it seems to me it should have noticed that the final commit recorded in the dump file was incomplete, and discarded it. Instead, it happily loaded it, and reported no problems. At least I was lucky enough to check that it was complete, and I used a technique <http://superuser.com/a/315138> to drop all but the last revision. Now I can load a new dump file from the commit that was incomplete. This brings me back to my question - shouldn't the load process ignore the last commit if it is incomplete in the dump file? That way I know I have an error to address! Eric.
