SCM-Manager/SVNKit 1.10.10 vs TortoiseSVN 1.14.9

[Paul, Jochen]

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.

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.

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 starting my quest here because of our daily work flags no problems with this tool combination. Maybe I'm wrong, so please apologize.

Freundliche Grüße / Kind regards,

i.A. Jochen Paul

Software Engineering

Research & Development

Fon: +49 6274 932 341

Joche...@mosca.com

    

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
in...@mosca.com

Allgemeine Informationen über den Umfang der Verarbeitung Ihrer personenbezogenen Daten und über Ihre Datenschutzrechte finden Sie hier.

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.

[Daniel Sahlberg]

Hi,

Since this question mainly concerns the repository format and not specifically TortoiseSVN (as a client application) it would be better if you post it on the Subversion mailing lists, see https://subversion.apache.org/mailing-lists.html

Just some quick thoughts though: Don't edit the uuid file manually. It should contain two UUIDs (the repository ID and the instance ID) on separate lines (LF line ending). (The instance id is only there in relatively recent repository formats - don't know if the 1.7 compatibility mode is recent enough). Can you restore an old repository backup and check the contents of that file?

Hope this helps!

Daniel

[John AC Lupe (John AC Lupe)]

Hi there,

we're using SCM-Manger with it's buildin SVNKit on Windows Server.

The SVN part is running well (checkout, list, commit, update, ...). For backup we export the repositories using svnrdump, the import via SCM-Manager (UI) or svnadmin load on the server will work as expected.

Our repositories needs somehow restructuring. For this I want to create a partial dump of a repository using a combination of svnadmin and svndumpfilter. Surprisingly the system reports errors:

svnadmin dump <path-to-repo>\data | svndumpfilter include <branchname> --renumber-revs --drop-empty-revs > dlp.dump

svnadmin: E070014: Can't read file '<path-to-repo>\data\db\uuid': End of file found
Including (and dropping empty revisions for) prefixes:

   ' <branchname>  '

svndumpfilter: E200003: Premature end of content data in dumpstream

I've already tried to use other commands to verify/fix the repository via CLI but without success. Even the manipulation of the UUID file like adding an additional UUID, force UTF-8 file format, force Linux EOL style and so on won't fix the issue.

Because of SVN (SCM-Manager as server and Tortoise SVN as client) works without any problems for our daily business I start here asking for help. On SCM-Manager SVN is configured for SVN 1.7 compatibility, for Tortoise SVN we do not use any special settings.

Can somebody point me please to the right direction to solve this issue?

[John AC Lupe (John AC Lupe)]

Hej Daniel,

thanks for your hint - I'll try to make myself familiar with the Apache SVN Mailinglist.

About the UUID file - I've just created a special repo for testing purposes, so nothing will be destroyed if some manual editing leaves the repo in an error prone status. You expected two UUIDs in this file? In fact there is only one...

Regards

Jochen

[Daniel Sahlberg]

Hi John,

The double UUIDs seems to be part of the Subversion 1.10 repository ondisk format (before this there was only one). As far as I can tell by looking at the code, svnadmin SHOULD be able to handle both formats, so it seems like svnadmin is confused and believe the repository has been upgraded to a newer format but the UUID file has not updated.

Can you check the contents of the [path\to\repository]\db\format file?

Are you using svnadmin from the TortoiseSVN command line tools or from SVNKit/SCM-Manager? Can you check svnadmin --version? If you are using the TortoiseSVN bundled svnadmin executable, the version should be 1.14.5 - maybe you can find an older svnadmin executable that works?

Kind regards,

Daniel

[John AC Lupe (John AC Lupe)]

Hej Daniel,

thank your for your response. The content of the format file is:

7
layout sharded 1000

There is an empty line after "layout..." before EOL. Just to complete the information, the content of the UUID file is:

30664206-048f-af42-9834-0175481554e7

The EOL is after the ID in a new line.

And yes, I'm using the svnadmin of the TortoisSVN CLI tools, the version info is:

svnadmin, version 1.14.5 (r1922182)
   compiled Nov 30 2024, 08:20:48 on x86-microsoft-windows

So this might be a problem with SVNKit writing meta data not valid for the TortoiseSVN CLI tools?

[Daniel Sahlberg]

måndag 10 augusti 2026 kl. 10:21:11 UTC+2 skrev john.a...@gmail.com:

Hej Daniel,

thank your for your response. The content of the format file is:

7
layout sharded 1000

I'm getting format 7 with svnadmin create --compatible-version=1.9, however I also get logical addressing:

7
layout sharded 1000
addressing logical

I think the logical addressing is optional so that probably doesn't matter.

What happened when you added a second UUID in the uuid file? Make sure to use only LF for newline and that you don't accidentally add a BOM to the file. (UTF-8 format shouldn't make a difference since the file will only contain basic ASCII characters - they are the same in all common western encodings).

There is an empty line after "layout..." before EOL. Just to complete the information, the content of the UUID file is:

30664206-048f-af42-9834-0175481554e7

The EOL is after the ID in a new line.

And yes, I'm using the svnadmin of the TortoisSVN CLI tools, the version info is:

svnadmin, version 1.14.5 (r1922182)
   compiled Nov 30 2024, 08:20:48 on x86-microsoft-windows

So this might be a problem with SVNKit writing meta data not valid for the TortoiseSVN CLI tools?

It seems so, yes. Do you get an svnadmin tool with the SVNKit installation? Or can you do the dump via svnrdump (you mentioned earlier that this works)?

What happens if you create a repository in SVNKit/SCM-manager with a newer (as new as you can possibly do) format?

/Daniel

[John AC Lupe (John AC Lupe)]

Hej Daniel,

the test repository I've created got the same content as already mentioned:

7
layout sharded 1000

SVNKit is a plain Java implementation as far as I know. I haven't found any CLI programs except the SCM-Manager itself.

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.

You made my day! Thank you for your support and

have a nice day!

Regards

Jochen

[Daniel Sahlberg]

Good to know!

I wouldn't normally recommend editing files within the repository structure, but this seems like a relatively safe change. (I assume you've checked that the repository still works within SVNKit/SCM-Manager).

Kind regards,

Daniel

[John AC Lupe (John AC Lupe)]

I understand what you mean and I'm with you. The risk to damage the repo is there...

Hm, yes, I've did a checkout, modified a file, committed it back and it seems to work. There have no errors been reported.

Thank you again. I'm not sure if the way to go is clear. As SVNKit is set to support SVN V1.7, the svnadmin utility seems to address SVN V1.9 (this is the version with two UUIDs in the file). Maybe I'll ask on the Apache mailing list...