User came back on the tortoisevn group: "Adding a random new UUID to the file enables svnadmin to dump as expected (and also filtered by svndumpfilter).
I'll check this with the guy of SCM-Manager, they should open a bug at SVNKit." So basically, SVNKit seems to not be completely compatible with the Subversion repo format.. Case closed. /Daniel Den mån 10 aug. 2026 kl 10:45 skrev Daniel Sahlberg < [email protected]>: > HI Jochen, > > Welcome to [email protected] > > For the readers here, this topic has already been discussed a bit on the > TortoiseSVN group, see > https://groups.google.com/g/tortoisesvn/c/-msg_dvvTdI > > Some comments from that discussion below. > > Den mån 10 aug. 2026 kl 10:36 skrev Paul, Jochen <[email protected]>: > >> Hi there, >> >> we're using SCM-Manager 3.11.7 as SVN Server. The software is running on >> Windows Server 2025. As client tool we're using Tortoise SVN 1.14.9. For >> our daily work the combination works like a charm. The SCM-Manager SVN >> plugin is set to SVN 1.7 compatibility mode. On the server Tortoise SVN is >> also installed including the CLI tools. The CLI tools are added to the path >> so they're available without any problems. >> > > The TortoiseSVN command line tools are straight up from the Subversion > project so I think this question belong here rather than on the TSVN group. > > >> >> Our backups are created with scripts. The dumps are created using the >> svnrdump command, the imports are done either using the UI of SCM-Manager >> or the svnadmin load command on the CLI. Both works as expected without any >> problems. >> >> Now some of our repositories needs some restructuring. Because of this I >> want to create a partial dump on the server using a combination of svnadmin >> dump and svndumpfilter. This results in an error. I'm using: >> >> svnadmin dump <path-to-repo>\data | svndumpfilter include <repobranch> >> --renumber-revs --drop-empty-revs > partial.dump >> svnadmin: E070014: Can't read file '<path-to-repo>\data\db\uuid': End of >> file found >> Including (and dropping empty revisions for) prefixes: >> '<repobranch>' >> >> svndumpfilter: E200003: Premature end of content data in dumpstream >> >> I've googled the SVN error, tried to force file format of the UUID file >> to be UTF-8, using Linux EOL style, added an additional UUID, replaced the >> complete file with a new one... No success. I've also tried to use commands >> like svnadmin verify and svnadmin fix to get rid of this problem, also >> without success. They result all in the same or in similar errors. As hint >> from the TortoiseSVN mailinglist somebody noted, that there should be two >> IDs in the UUID file - in fact there is only one. >> > > We have checked the contents of the db\format file, that indicate: > > 7 > layout sharded 1000 > > I checked on my side with svnadmin create --compatible-version=1.9 and I > also get format 7 (but with logical addressing) and in the uuid file I have > two UUIDs. > > >> Currently I'm puzzled and do not have any idea to succeed. I'll be happy >> if somebody can point me to the right direction to solve this issue. I'm >> continuing my quest here after somebody at TortoiseSVN redirected me to >> here. Our daily work flags no problems with this tool combination. Maybe >> I'm wrong, so please apologize. >> > > Is this an issue where SVNKit creates a repository where the ondisk format > is not compatible with what our tools expect? > > I have suggested to create the repositories with as high version as SVNKit > can support to see if there is a difference. I have also suggested to do > the dump via svnrdump since that use SVNKit's repo layer which seems to be > fine with the repository ondisk format. > > Cheers, > Daniel > > >> >> Freundliche Grüße / Kind regards, >> *i.A. Jochen Paul* >> Software Engineering >> Research & Development >> Fon: +49 6274 932 341 <+49%206274%20932%20341> >> [email protected] >> >> >> <https://www.linkedin.com/company/mosca-gmbh> >> <https://www.instagram.com/moscagmbh> >> <https://www.facebook.com/Mosca.gmbh> >> <https://www.youtube.com/user/MoscaStrapping> >> >> [image: 2026-07_TOP100.png] >> >> MOSCA GmbH >> Gerd-Mosca-Strasse 1 >> D-69429 Waldbrunn >> Geschäftsführer/-in / CEO: Timo Mosca, Simone Mosca, Alfred Kugler >> Gerichtsstand / Court: Mannheim HRB 718516 >> Umsatzsteuer ID-NR. / Salestax ID-No.: DE 222 583 604 >> >> <https://www.mosca.com> >> https://www.mosca.com >> [email protected] >> >> Allgemeine Informationen über den Umfang der Verarbeitung Ihrer >> personenbezogenen Daten und über Ihre Datenschutzrechte finden Sie hier >> <https://www.mosca.com/de-de/unternehmen/meta/rechtliche-hinweise/verarbeitung-personenbezogener-daten/> >> . >> >> Diese E-Mail (einschließlich ihrer eventuellen Anlagen) enthält >> vertrauliche und/oder vom Berufsgeheimnis umfasste oder sonstige geschützte >> Informationen. Wenn Sie nicht der vorgesehene Adressat sind, kopieren Sie >> diese E-Mail nicht, unterlassen Sie jegliche Nutzung sowie Weitergabe >> und löschen Sie diese von Ihrem System. Mosca GmbH übernimmt keinerlei >> Haftung, falls diese E-Mail Viren enthält oder im Wege ihrer Übertragung >> geändert oder verfälscht wurde. Der Inhalt dieser E-Mail stellt keine >> rechtverbindliche Erklärung dar, sofern dies nicht ausdrücklich schriftlich >> vereinbart wurde. >> >> This email (including any attachments) contains confidential and/or >> privileged information or information otherwise protected from disclosure. >> If you are not the intended recipient, do not copy this message or any >> attachments and do not use it for any purpose or disclose its content to >> any person, but delete this message and any attachments from your system. >> Mosca GmbH disclaims any and all liability if this email transmission was >> virus corrupted, altered or falsified. The content of this e-mail does not >> constitute a legally binding declaration unless this has been expressly >> agreed in writing. >> >
