tags:

views:

109

answers:

3

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?

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.

Any ideas?

A: 

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

Achilles
I think he's talking about stripping a very complex structure (with several moves inside it) from a repo that contains a lot more.
Pekka
You can't use hotcopy for this, that can only be used to make full copies of repositories
Sander Rijken
+1  A: 

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

Zac Thompson
+2  A: 

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

scherand
I didn't know about svndumpfilter2 but it seems to be what I'm looking for. I'm going to try it and see how it works out.
chotchki
I haven't finished my migration effort yet (huge repo 30k+ commits) but this method looks promising.
chotchki