How to migrate a codebase from one svn repo to another preserving history?

I have a branch in a badly structured svn repo that needs to be stripped out and moved to another svn repository. (I’m trying to clean it up some).

If I do an svn log and not stop on copy/rename I can see all 3427 commits that I care about. Is there some way to dump the revisions out, short of writing some major scripts?

  • $id: name of file, date/time creation Exp $
  • Submitting Hg changes back to SVN
  • svn: dump format documentation?
  • Does git have anything like `svn propset svn:keywords` or pre-/post-commit hooks?
  • What's the benefits of “svn:externals”?
  • Git svn work flow, making branchs in git-svn
  • I would follow the advice in this question but this branch has been moved all over the place and I would like to preserve the moves as well.

  • Using Git or Hg, if the whole team is using pull and push from a central server, how is it different from SVN?
  • If statements in .htaccess files, to enable password protection when in specific directory only
  • Subversion Proxy for working offline?
  • Searching subversion history (full text)
  • Subversion vs CVS
  • SVN Libraries for .NET?
  • 4 Solutions collect form web for “How to migrate a codebase from one svn repo to another preserving history?”

    I guess this might be similar to what @ZacThompson (and @Pekka) mean: I think svndumpfilter is your friend.

    From your question I think you have the idea what it is meant to do but struggle with the copying/moving of the branch all over the place? An answer to that can be found in the before mentioned SVN Documentation, I believe:

    Also, copied paths can give you some
    trouble. Subversion supports copy
    operations in the repository, where a
    new path is created by copying some
    already existing path. It is possible
    that at some point in the lifetime of
    your repository, you might have copied
    a file or directory from some location
    that svndumpfilter is excluding, to a
    location that it is including. To make
    the dump data self-sufficient,
    svndumpfilter needs to still show the
    addition of the new path—including the
    contents of any files created by the
    copy—and not represent that addition
    as a copy from a source that won’t
    exist in your filtered dump data
    stream. But because the Subversion
    repository dump format shows only what
    was changed in each revision, the
    contents of the copy source might not
    be readily available. If you suspect
    that you have any copies of this sort
    in your repository, you might want to
    rethink your set of included/excluded
    paths, perhaps including the paths
    that served as sources of your
    troublesome copy operations, too.

    Meaning: make svndumpfilter include all paths the branch ever lived at. Or am I missing something?

    Another possibility might be the svndumpfilter2 mentioned by @compie in the thread you linked although I believe it is not even necessary (and I don’t know either of @compie or svndumpfilter2).

    You will want to use some combination of:

    1. svnadmin dump
    2. svndumpfilter
    3. svnadmin load

    If you want to do the whole branch, you may not even need svndumpfilter. But if you do:

    http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.filtering

    There is another solution that is pretty simple and solves the “preserve the moves” issue. Please see the last paragraph of the Apache Subversion FAQ entry “How do I completely remove a file from the repository’s history?”. The solution does not rely on the svndumpfilter.

    You can perform the following steps:

    1. Configure path-based authorization rules to deny read access for a USERNAME account to the PATHS of the file or a folder you want to remove from repository history.

      Please note the plural noun paths. The file or folder you want to get rid of could have different names or can be located in different places across a repository history. Please consider this when setting up deny rules.

    2. Create an empty repository,

    3. Replicate the source repository with svnsync tool to the target repository under account USERNAME. For details on repository synchronization with svnsync please refer to SVNBook chapter “Repository Replication”.

    Unlike svndumpfilter, svnsync automatically translates svn copy operations with an unreadable source path into normal additions, which is useful if history involves copy operations and still needs to be filtered. 🙂

    You need to use HotCopy to backup the repository directory. Then it should be a matter of simply restoring the repository.

    Git Baby is a git and github fan, let's start git clone.