Svnadmin load from dumpfile causes “file not found

Question

Given:

Repository_1 - source

Repository_2 - destination

I created a dump file of Repository_1/Folder1 using combination of svnadmin and svndumpfilter

When loading from the dump file from Repository_1/Folder1 into Repository_2/Trunk everything is fine BUT

When loading from Repository_1/Folder1/Sub-folder(created another dump for this) into Repository_2/trunk i get the following error:

svnadmin: File not found: transaction '267-89', path 'trunk/Folder1/Sub-folder'

Can anyone explain?

Answer 1

Loading the dump fails because trunk/Folder1 creation was filtered by svndumpfilter. According to this blog post, these steps are needed on the dump :

You can create trunk/Folder1 in the dump, by editing the dump itself and add to the first revision the following block:

Node-path: trunk/Folder1
Node-action: add
Node-kind: dir
Prop-content-length: 10
Content-length: 10
PROPS-END

This block must be inserted in the props blocks of the first revision.

Then the dump can be loaded with svnadmin.

Answer 2

you'll get this error if someone copied something from trunk/Folder1 to trunk/Folder1/Sub-folder. since you have only included trunk/Folder1/Sub-folder in your dump, it cannot find the required file(s) from trunk/Folder1 anymore and stops with this error.

to solve this you'll have to make sure to include everything in the dump that has been the source of a copy.

Answer 3

I have just experienced this error which I traced to a recent server upgrade and a svnadmin dump/load cycle. The problem was that I had set up the repository in a different directory to the one it was created in.

On the old machine, I was using inetd.conf to run svnserve:

svnserve -r /var/svn/main

and the repository was in /var/svn/main

However on the new machine I had inetd.conf pointing to /var/svn:

svnserve -r /var/svn

I already had a checkout from the old server, so when I tried to commit the destination path didn't exist because I'd accidentally added another component to the URL, so svn://host/source/trunk became svn://host/main/source/trunk.

I could have fixed it by moving the directories around, but I chose instead to rewrite the URL of the working copy using svn switch --relocate.

Note: a quick diagnostic to see whether this is the problem is to change to a directory in your working copy, type svn info to get the repository URL and then type svn ls <myUrl>. If this gives a No repository found error then you know this is the cause.

Answer 4

Turns out that structure(empty folders) in destination needs to pre-created. So, If you want to do this:

When loading from Repository_1/Folder1/Sub-folder(created another dump for this) into Repository_2/trunk

you need to created this structure in svn

Repository_2/trunk/Folder1

note: you only need to create parents, not the folder itself, so DO NOT CREATE Repository_2/trunk/Folder1/Sub-folder

Answer 5

As noted in this thread, svnrdump works differently from svndump.

svndump + svndumpfilter:

• Dumps the entire repository history, then filters for the things you want. This takes a long time on large repositories, even if you're just grabbing a tiny subtree.
• Produces a dumpfile that is probably broken in a number of ways, like creating files in directories that don't exist or copying files from paths that don't exist.

svnrdump:

• Produces a self-consistent dumpfile.
• Requires a subpath if you want to do the equivalent of svndumpfilter include. For example, svnrdump https://server.example.com/svn/repo/branches/1.4 would grab all the revisions affecting /branches/1.4.
• May require an additional | svndumpfilter include / --drop-all-empty-revs --renumber-revs.

Bottom line: svnrdump will probably work better.