Merge a Branch into Trunk

Question

I'm facing a peculiar problem with SVN merge. I want to merge from a dev branch to trunk. We have multiple dev branches cut off the trunk at the same time.

I'm merging one of those branches to trunk with this command:

svn merge trunk branch_1

I see changes that are not part of this branch, getting merged into trunk. What am I doing wrong ?

SVN Version :

Subversion command-line client, version 1.6.16-SlikSvn-tag-1.6.16@1076804-WIN32.

Solution 1

Your svn merge syntax is wrong.

You want to checkout a working copy of trunk and then use the svn merge --reintegrate option:

$ pwd
/home/user/project-trunk

$ svn update  # (make sure the working copy is up to date)
At revision <N>.

$ svn merge --reintegrate ^/project/branches/branch_1
--- Merging differences between repository URLs into '.':
U    foo.c
U    bar.c
 U   .

$ # build, test, verify, ...

$ svn commit -m "Merge branch_1 back into trunk!"
Sending        .
Sending        foo.c
Sending        bar.c
Transmitting file data ..
Committed revision <N+1>.

See the SVN book chapter on merging for more details.

---

Note that at the time it was written, this was the right answer (and was accepted), but things have moved on. See the answer of topek, and http://subversion.apache.org/docs/release-notes/1.8.html#auto-reintegrate

Solution 2

If your working directory points to the trunk, then you should be able to merge your branch with:

svn merge https://HOST/repository/branches/branch_1

be sure to be to issue this command in the root directory of your trunk

Solution 3

Do an svn update in the trunk, note the revision number.

From the trunk:

svn merge -r<revision where branch was cut>:<revision of trunk> svn://path/to/branch/branchName

You can check where the branch was cut from the trunk by doing an svn log

svn log --stop-on-copy

Solution 4

The syntax is wrong, it should instead be

svn merge <what(the range)> <from(your dev branch)> <to(trunk/trunk local copy)>

View more solutions

Comments

[Vanchinathan Chandrasekaran]

Since there are multiple dev branches that are alive at the same time, this was also not working for me, this command was pulling in changes from other branches as well. May be this is a problem with SLik SVN client?

[blahdiblah]

While this isn't inaccurate, there are easier ways to merge with more recent versions of svn (such as the one OP is using).

[Lazy Badger]

--reintegrate option isn't mandatory, branch (in 1.6) can be merged with any-destination any number of times

[Neutrino]

Really? Without risking remerging the same changesets? Can you provide a link to corroborating evidence of this please.

[tibo]

--reintegrate is indeed not mandatory but really recommended in this case. I have tried to do it without --reintegrate and ended up with hundred of conflicts. With --reintegrate, no conflicts and everything was good!

[Pino]

The --reintegrate option is simple and effective, BUT it must be noted that "Once a --reintegrate merge is done from branch to trunk, the branch is no longer usable for further work. It's not able to correctly absorb new trunk changes, nor can it be properly reintegrated to trunk again." as explained by the book you have linked.

[Dave Lawrence]

@Pino, but that in itself is not a bad thing... If you were to continue to use that branch after performing a non reintegrate merge; while at the same time other concurrent branches were being merged into trunk, you would constantly end up in situations where forward merges from trunk to branch are required...

[Pino]

@daveL, forward merges from trunk to branch make sense to me. However I have found an advanced feature to "keep a reitegrated branch alive" (see stackoverflow.com/a/10163059/685806), furthermore it is applied automatically by newer client versions.

[GreenAsJade]

As of SVN 1.8. this is the right answer. See subversion.apache.org/docs/release-notes/…

[Mike]

@Pino so if I understand correctly, if I have branches: mike, joe (developers) and trunk (managed by leader). Each time mike says his branch is stable, the leader has to merge mike's branch into his own working copy, then commit to trunk and let joe know that trunk was updated and that joe should merge trunk into his working copy. Correct? (this scenario works both ways, for more developers, each dev would have to merge trunk into his working copy).

[Pino]

@Mike, almost correct, but I think that having a branch for each developer is not so common, usually people use a branch for each flow of development (for example trunk for the new release and branch for bugfixes of the current release).

[ahnbizcad]

screw the SVN book chapter on merging. topek's answer is x10000 better and shorter

[ahnbizcad]

@blahdiblah the code snippet has a lot of extraneous info. There's a reason why the abstract of studies get read orders of magnitude more than any other part of a study. The same goes for UX testing, minimizing bounce rates, etc. It's all the same principle.

[John Little]

with 1.7 you could merge without the --reintegrate option, and keep developing on the branch and keep merging. Sadly, 1.8 will force this to be a reintegration, and there doesnt seem to be a way to prevent it. This means as soon as you merge, you cannot then use the branch without going through the dreaded "keep-alive dance"

[John]

Don't forget to then commit the working copy of the trunk back to the repository after the merge!

[Fredrick Gauss]

@VanchinathanChandrasekaran, in the command you specify branch name as svn://path/to/branch/branchName that should pull only the changes from that branch not from other branches. If so we are in the danger!

[Jake Jackson]

I have come back to this so many times. A literal handbook :)