19

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/build.properties ... 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?

Thanks!

Harlan
  • 291
  • 2
  • 5
  • 1
    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
  • 1
    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
  • 3
    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
  • There are better svndumpfilter-like tools out there that try harder to make the resulting dump importable. Try svndumpfilter2 and/or svndumpfilter3 (google finds them easily). – András Korn Sep 01 '14 at 15:36
  • What options did you run svndumpfilter with? Are you renumbering or skipping empty merge sources? – shooper Mar 19 '15 at 19:25
  • @vonbrand I am running into OP's problem while trying to migrate to git (and splitting a multi-project repository into single-project repositories) – Marcel Waldvogel Feb 09 '20 at 08:26

2 Answers2

2

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.

grp=$cust_group
usr=$cust_customer
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.

ciuly
  • 196
  • 5
2

I have used a great tool svndumpsanitizer. The problem is that the subversion repository structure is too complicated. When svndumpfilter is at revision 10, it has no way of knowing whether a node the user wants to discard, will be moved to a position he wishes to keep in revision 113. So it does the only thing it can do - it discards the node, and at revision 113 craps out because it has already discarded the data it turns out it would have needed.

Svndumpsanitizer works in a different manner. It scans the nodes several times in order to discover which nodes should actually be kept. After it has determined which nodes to keep it writes only these nodes to the outfile. Finally - if necessary - it adds a commit that deletes any unwanted nodes that had to be kept in order not to break the repository.

ALex_hha
  • 7,025
  • 1
  • 23
  • 39