svnsvndumpsvndumpfilter

SVNDumpFilter changing paths before adding them?


I'm using svndumpfilter to extract single projects from a larger repo and import them into their own repo. Something like this:

svndumpfilter include --drop-empty-revs --renumber-revs Trunk/Source/Project1 < full.dump > Project1.dump

It worked okay with one project, but on the second one, I notice that the resulting filtered dump does not start by adding a path. See the first two revisions (renumbered):

SVN-fs-dump-format-version: 2

UUID: c6612063-4e6b-459c-a579-78605fb1e4b5

Revision-number: 0
Prop-content-length: 56
Content-length: 56

K 8
svn:date
V 27
2010-05-11T20:45:07.903005Z
PROPS-END

Revision-number: 1
Prop-content-length: 128
Content-length: 128

K 7
svn:log
V 27
Fixed code after branching.
K 10
svn:author
V 6
somedude
K 8
svn:date
V 27
2010-09-21T23:07:51.719341Z
PROPS-END

Node-path: Trunk/Source/Project1/Project1.csproj
Text-content-md5: 9d127596909e2a9921f1ec1c0223e1ed
Node-action: change
Text-content-sha1: 22eb675e0a5bfb41092de6ed39dc7c4d2a15dbd5
Node-kind: file
Text-content-length: 5178
Content-length: 5178

Notice how it is trying to "change" Trunk/Source/Project1/Project1.csproj before it ever added it in the first place? Not surprisingly, I get "file not found" when running svnadmin load on the filtered dump. Any ideas?


Solution

  • There are three ways:

    1. Add missing folder via commit before loading dump file: svn mkdir http://server/svn/project/Trunk -m "Created Trunk"
    2. Manually add a node record that creates Trunk folder to the dump:

      Revision-number: 1
      Prop-content-length: 128
      Content-length: 128
      
      K 7
      svn:log
      V 27
      Fixed code after branching.
      K 10
      svn:author
      V 6
      somedude
      K 8
      svn:date
      V 27
      2010-09-21T23:07:51.719341Z
      PROPS-END
      
      Node-path: Trunk/
      Node-kind: dir
      Node-action: add
      Prop-content-length: 48
      Content-length: 48
      
      PROPS-END
      
      
      Node-path: Trunk/Source/Project1/Project1.csproj
      Text-content-md5: 9d127596909e2a9921f1ec1c0223e1ed
      Node-action: change
      Text-content-sha1: 22eb675e0a5bfb41092de6ed39dc7c4d2a15dbd5
      Node-kind: file
      Text-content-length: 5178
      Content-length: 5178
      
    3. Don't use svndumpfilter at all, because it's broken by design (svndumpsanitizer's home page has a good explanation why). There is a good chance, that you will encounter other errors further in your dump.

    I'm currently in a process of splitting a devilishly complex repo with a lot of merges, moves and other such things and I can say that there is nothing around that handles splitting svn dumps 100% properly.

    For example well-known svndumpfilterIN contains at least three major bugs (I've only managed to report one of them and other two are much more evil) and failed miserably on my repo. I'll try to share a fixed version of it on GitHub some time later, but in it's current state I can't recommend it.

    So in my opinion, your best chance is to try abovementioned svndumpsanitizer without --redefine-root option, because it's bugged too (bugreport coming). If you're on Windows, it compiles fine with the latest Visual Studio Community 2013 (free).


    Updated in Y2K17

    The last two paragraphs above are no longer relevant, since I've fixed all the issues in the svndumpfilterIN, that were stopping me from converting my repo. My PR has been merged to the base repo, so give it a try. I still can't guarantee 100% success, but your chances are much higher now.