What is the best way to make one of the branches of a subversion repository the new trunk?
There has been a major rewrite for the entire system: t
@Aaron Digulla and @kementeus solutions are workable. For Subversion 1.4 repositories, copy/move operations can make future migration to a different repository structure or splitting repositories difficult.
I believe 1.5's improvements include better resolution of move/copy history, so it probably wouldn't be an issue for a 1.5 repository.
For a 1.4 repository, I'd recommend using svnadmin dump
and svndumpfilter
to perform the movement of the existing trunk elsewhere, then moving the branch to the trunk with the same mechanism. Load the two dumpfiles into a test repository, verify, then move it to production.
Of course, backup your existing repository before starting.
This preserves history without recording the move/copy explicitly and makes future re-organization, preserving history, easier.
Edit: As requested, the documentation of the 1.4 behavior, from the 1.4 Red-Bean book, Filtering Repository History
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. In order 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 only shows 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.
This applies to migrations/reorganizations using svndumpfilter
. There are times when a little extra work now can save a lot of extra work later, and by keeping an easy use of svndumpfilter
available for future migrations/reorganizations mitigates the risk at a relatively low cost.
If you want to make the branch the new trunk (i.e.) get rid of all changes in the trunk which were made since the branch was created, you could 1. Create a branch of the trunk (for backup purposes) 2. "revert changes" on the trunk (select all revisions after the branch was created 3. Merge branch back to trunk.
History should be remaining this way.
Regards, Roger