Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I'm trying to learn how to migrate a Subversion repo, and am running into an issue that doesn't make sense to me. I've used svndumpfilter to split out a sub-project, and have removed some path prefixes. Several hundred commits now import correctly, but then I'm getting the following error:

<<< Started new transaction, based on original revision 19190
     * editing path : branches/features/DynamicSource ... done.
     * editing path : branches/features/DynamicSource/src/ ... done.
     * editing path : branches/features/DynamicSource/src/client/default.htm ...done.
     * editing path : branches/features/DynamicSource/src/client/js/AdHocController.js ... done.
     * editing path : branches/features/DynamicSource/src/client/js/Report.js ... done.
svnadmin: E160006: No such revision 19098
     * adding path : branches/features/DynamicSource/src/client/js/Enums.js ...

OK, so I go into the dump file to look at revisions 19190 and 19098. First of all, revision 19098 does exist in the dump file and was imported without a problem. Revision 19190 is a merge. Within 19190, here's that last file's info, which seems to be causing the issue:

Node-copyfrom-rev: 19100
Node-copyfrom-path: trunk/src/client/js/Enums.js
Text-copy-source-md5: 2db7f8d9c0ba4750d88ce0722731aad6
Node-path: branches/features/DynamicSource/src/client/js/Enums.js
Node-action: add
Text-copy-source-sha1: 8f930509f8dbc17c5e82cd40aa5a76454d3d812c
Node-kind: file
Content-length: 0

Confusingly, revision 19100 does NOT exist in this filtered file. But the error's not referring to 19100, it's referring to 19098!

What do I do to get this file to load?


share|improve this question
If something complicated ("dump and filter" followed by "import") fails, try something simpler first ("dump", then "import"). I only ever migrated a whole repo, and that went easy-peasy. – Dirk Eddelbuettel Aug 29 '13 at 13:39
Thanks, Dirk. We really do have to split this repo up, though. – Harlan Aug 29 '13 at 13:40
Maybe do "Dump, Import. Hand-reduce, Dump again. Import 2nd Dump." ? – Dirk Eddelbuettel Aug 29 '13 at 13:41
Unless I'm missing something, I don't think SVN works that way. You have to reduce using the dump file and svndumpfilter. And we do want to keep history, as much as possible. – Harlan Aug 29 '13 at 14:08
Why not migrate to git or mercurial, and get rid of the legacy SVN in the same step? – vonbrand Jan 24 '14 at 17:21

1 Answer 1

I've done this kind of splitting many times. I think it all depends on how you use the filter and what processing you do on the dump file afterwards. Personally, I also had to change the svn user, beside the project path, and renumber revisions. Just so you can see what can be done, here is relevant part of my script.

svndumpfilter include $grp/$usr --drop-empty-revs --renumber-revs  <$repo_dump > $repo_dump.$usr
sed -e "s/Node-path: $grp\/$usr/Node-path: /" <$repo_dump.$usr >$repo_dump.$usr.fixed1
sed -e "s/Node-copyfrom-path: $grp\/$usr/Node-copyfrom-path: /" <$repo_dump.$usr.fixed1 >$repo_dump.$usr.fixed2
sed -e "/Node-path: /{ N; N; N; N; N; N; s/Node-path: \nNode-action: add\nNode-kind: dir\nProp-content-length: 10\nContent-length: 10\n\nPROPS-END//}" <$repo_dump.$usr.fixed2 >$repo_dump.$usr.fixed3
sed -e "/svn:author/{ N; N; s/svn:author\n.*\n$svn_usr_from/svn:author\nV $svn_usr_len\n$svn_usr_to/}" <$repo_dump.$usr.fixed3 >$repo_dump.$usr.fixed4
svnadmin load $repo_dir/$cust_group/$cust_customer --ignore-uuid < $repo_dump.$usr.fixed4

chown svn:svn -R $repo_dir/$cust_group/$cust_customer
#chown apache $repo_dir/$cust_group/$cust_customer/db/txn-current
#chown apache $repo_dir/$cust_group/$cust_customer/db/current
# apache is in svn group so the above 2 are not needed
chmod -R g+rw $repo_dir/$cust_group/$cust_customer

What happens there is that first, I filter out what I need, I drop the empty revisions for obvious reasons and I renumber them. This gives nice ordered revisions. Then I drop the root path of the project which in my case was in the form of group/customer because in the new repo that has no sense (instead the repo itself is group/customer on disk) - this is the first 2 sed's

Following, I remove the import of non-named directories, one resulting from the above 2 seds for the group dir and then one for the group/customer dir adding.

finally, I sed the author to change it to a new one. This one was a bit tricky too as it required updating the length of the property definition.

Then I load it up and fix-up the filesystem permissions. Note the 2 commented chowns for apache, in some cases you will need it. I eventually ended up adding apache to svn group.

Now, I never had merges in my SVN repo's so I never had to deal with them for the split. In your case, I would imagine that what happens is the source revision path is not imported and that is why it doesn't find it even though the error complains on the revision itself). The rule of thumb in the svn import file is that anything that is referred to at one point must have been already imported prior to it being referred. So you may have filtered out something that you shouldn't, even though you want it, or not updated the dump file correctly to reflect whatever other changes you've made.

If you provide the relevant structure of your original repo, including the merged source path, plus your calls with parameters, I may be able to tel you what you missed. My money is on the source of the merge.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.