Hi Daniel, you are a guru. I don't know why but it worked! I guess the magic is in the difference of network transmission of svnsync vs svnrdump / svnadmin load
Are there suggestions from your side to avoid this error in the future? Thank you very much for your help!!! Regards Thomas -----Original Message----- From: Daniel Shahaf [mailto:danie...@apache.org] Sent: Donnerstag, 8. Dezember 2016 07:20 To: Stümpfig, Thomas (DF PL S&SE DE PSM EAI) <thomas.stuemp...@siemens.com> Cc: Pavel Lyalyakin <pavel.lyalya...@visualsvn.com>; users@subversion.apache.org Subject: Re: svnsync on large files Stümpfig, Thomas wrote on Wed, Dec 07, 2016 at 23:32:38 +0000: > This is the situation of the starting point. (I restored) The steps should be this: f() { token="$USER@$(hostname):${RANDOM}:${RANDOM}" svn propset --revprop -r0 -- svn:sync-lock $token svn propget --revprop -r0 --strict svn:sync-lock | fgrep -q -- $token || return 1 svn propset --revprop -r0 svn:sync-currently-copying 54618 svnrdump dump -r54618 --incremental https://mysourceturl/repository >tmpfile svnadmin load /svnmirror/projektablage <tmpfile svn propset --revprop -r0 svn:sync-last-merged-rev 54618 svn propdel --revprop -r0 svn:sync-currently-copying svn propdel --revprop -r0 svn:sync-lock } Note: 1. Using the same metadata revprops and order as svnsync. 2. The fgrep is to make up for the svn:sync-lock not being taken atomically. (The cmdline client passes NULL for the ORIGINAL_PROPVAL argument of svn_client_revprop_set2().) 3. Using a tmpfile since the dumpfile format isn't truncation-safe. 4. $RANDOM isn't in POSIX; if not available, substitute the first N bytes from /dev/urandom. 5. Make sure to use the correct source URL on the dump command. 6. The hooks may need tweaking. Cheers, Daniel ----------------- Siemens Industry Software GmbH; Anschrift: Franz-Geuer-Str. 10, 50823 Köln; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Urban August, Daniel Trebes; Sitz der Gesellschaft: Köln; Registergericht: Amtsgericht Köln, HRB 84564
