[ACCEPTED]-svn: replace trunk with branch-version-control

Use svn move to move the contents of the old trunk 12 somewhere else and rename the branch to 11 trunk afterward.

Note that copy and move 10 in svn work like file operations. You can 9 use them to move/copy stuff around in your 8 repository and these changes are versioned 7 as well. Think of "move" as "copy+delete".

[EDIT] Nilbus 6 just notified me that you will get merge 5 conflicts when you use svn move.

I still think that 4 this is the correct approach. It will cause 3 conflicts but if you merge carefully, chances 2 are that you won't lose any data. If that 1 bothers you, use a better VCS like Mercurial or Git.

I agree with using the svn move command 13 to accomplish this goal.

I know others here 12 think its unusual, but I like to do it this 11 way. When I have a feature branch and am 10 ready to merge it with a trunk that has 9 also be significantly modified, I will merge 8 it to a new branch, usually named <FeatureBranchName>-Merged. Then 7 I resolve conflicts and test the merged 6 code. Once that's complete I move the trunk 5 to the tags folder so I don't lose anything. Lastly 4 I move my <FeatureBranchName>-Merged to the trunk.

In addition I prefer 3 to avoid the working copy when doing the 2 moves, here are samples of the commands:

svn move https://SVNUrl/svn/Repo/trunk https://SVNUrl/svn/Repo/tags/AnyName

svn move https://SVNUrl/svn/Repo/branches/BranchName-Merged https://SVNUrl/svn/Repo/trunk

Note: I 1 use 1.5

I was just looking at this problem recently, and 12 the solution that I was very happy with 11 was performing

svn merge --ignore-ancestry 10 trunk-url branch-url

on the working copy 9 of my trunk.

This does not try to apply changes 8 in a historical manner (maintaining changes 7 in the trunk). It simply "applies the diff" between 6 the trunk and the branch. This will not 5 create any conflicts for your users in the 4 files that were not modified. You will however 3 lose your Historical information from the 2 branch, but that happens when you peform 1 a merge anyway.

Recommend you do these changes via the repository 7 browser tool.

Attempting large delete+move 6 operations via the working copy is a great 5 way to kill the working copy. If you are 4 forced to use the working copy, perform 3 incremental commits after each delete or 2 move operation and UPDATE your working copy 1 after each commit.

If you want to make the branch the new trunk 8 (i.e.) get rid of all changes in the trunk 7 which were made since the branch was created, you 6 could 1. Create a branch of the trunk (for 5 backup purposes) 2. "revert changes" on 4 the trunk (select all revisions after the 3 branch was created 3. Merge branch back 2 to trunk.

History should be remaining this 1 way.

Regards, Roger

@Aaron Digulla and @kementeus solutions 47 are workable. For Subversion 1.4 repositories, copy/move 46 operations can make future migration to 45 a different repository structure or splitting 44 repositories difficult.

I believe 1.5's improvements 43 include better resolution of move/copy history, so 42 it probably wouldn't be an issue for a 1.5 41 repository.

For a 1.4 repository, I'd recommend 40 using svnadmin dump and svndumpfilter to perform the movement of the 39 existing trunk elsewhere, then moving the 38 branch to the trunk with the same mechanism. Load 37 the two dumpfiles into a test repository, verify, then 36 move it to production.

Of course, backup 35 your existing repository before starting.

This 34 preserves history without recording the 33 move/copy explicitly and makes future re-organization, preserving 32 history, easier.

Edit: As requested, the 31 documentation of the 1.4 behavior, from 30 the 1.4 Red-Bean book, Filtering Repository History

Also, copied paths 29 can give you some trouble. Subversion 28 supports copy operations in the repository, where 27 a new path is created by copying some already 26 existing path. It is possible that at 25 some point in the lifetime of your repository, you 24 might have copied a file or directory 23 from some location that svndumpfilter is excluding, to 22 a location that it is including. In order 21 to make the dump data self-sufficient, svndumpfilter needs to 20 still show the addition of the new path—including 19 the contents of any files created by the 18 copy—and not represent that addition as 17 a copy from a source that won't exist 16 in your filtered dump data stream. But 15 because the Subversion repository dump 14 format only shows what was changed in 13 each revision, the contents of the copy source 12 might not be readily available. If you 11 suspect that you have any copies of this 10 sort in your repository, you might want 9 to rethink your set of included/excluded 8 paths, perhaps including the paths that served 7 as sources of your troublesome copy operations, too.

This 6 applies to migrations/reorganizations using 5 svndumpfilter. There are times when a little extra work 4 now can save a lot of extra work later, and 3 by keeping an easy use of svndumpfilter available for 2 future migrations/reorganizations mitigates 1 the risk at a relatively low cost.

While the answers above will work, they 11 aren't best practice. The latest svn server 10 and client track merges for you. So svn 9 knows which revisions you've merged into 8 a branch and from where. This helps a lot 7 when keeping a branch up-to-date and then 6 merging it back into the trunk.

No matter 5 which version of Subversion you're using 4 however, there is a best practice method 3 for getting changes in a branch back into 2 trunk. It is outlined in the Subversion 1 manual: Version Control with Subversion, Chapter 4. Branching and Merging, Keeping a Branch in Sync.