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?
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
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.
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.
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.
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.