The svn merge command applies the differences between two sources to a working copy path.
The synopsis is:
svn merge [-c M[,N...] | -r N:M ...] <source>[@svn_revision] <target>
or
svn merge --reintegrate <source>[@svn_revision] <target>
or
svn merge <source1>[@svn_revision_N] <source2>[@svn_revision_M] <target>
In all three forms <target> is the working copy path that will
receive the differences. If <target> is omitted, the changes are
applied to the current working directory, unless the sources have
identical basenames that match a file within the current working
directory. In this case, the differences will be applied to that file.
In the first two forms, <source> can be either a URL or a working
copy path (in which case its corresponding URL is used). If the peg
revision "svn_revision" is not specified, then HEAD (latest svn
revision) is assumed. In the third form the same rules apply for
<source1>, <source2>, "svn_revision_N", and "svn_revision_M"
with the only difference being that if either source is a working copy
path, then the peg revisions must be explicitly stated.
Sync and Cherrypick Merges
The first form, when used without either the -c or -r options, is called
a “sync” merge and -r 1:svn_revision is implied. This variant is used
to merge all eligible changes to a branch from its immediate ancestor
branch.
When the first form is used with the -c or -r options, this is called a
“cherrypick” merge and is used to merge an explicitly defined set of
changes from one branch to another.
Multiple -c and/or -r instances may be specified, and mixing of
forward and reverse ranges is allowed— the ranges are internally
compacted to their minimum representation before merging begins (which
may result in a no-op merge or conflicts that cause the merge to stop
before merging all of the requested revisions).
In both variants of the first form, <source> in revision
"svn_revision" is compared as it existed between revisions
"svn_revision_N" and "svn_revision_M" for each revision range provided.
Reintegrate Merges
The second form is called a “reintegrate merge” and is used to bring
changes from a feature branch (<source>) back into the feature
branch's immediate ancestor branch (<target>). Reintegrate merges
support only this specialized use case and as such have a number of
special requirements and limitations that the other two merge forms do
not posses.
2-URL Merges
In the third form, called a “2-URL Merge”, the difference between
<source1> at revision "svn_revision_N" and <source2> at
revision "svn_revision_M" is generated and applied to <target>.
The revisions default to HEAD if omitted.
If Merge Tracking is active, then Subversion will internally track
metadata (i.e. the svn:mergeinfo property) about merge operations when
the two merge sources are ancestrally related—if
the first source is
an ancestor of the second or vice versa—this is guaranteed to be the
case when using the first two forms. Subversion will also take
preexisting merge metadata on the working copy target into account when
determining what revisions to merge and in an effort to avoid repeat
merges and needless conflicts it may only merge a subset of the
requested ranges.
Merge Tracking can be disabled by using the --ignore-ancestry option.
Unlike svn diff, the merge command takes the ancestry of a file into
consideration when performing a merge operation. This is very important
when you're merging changes from one branch into another and you've
renamed a file on one branch but not the other.
Examples:
Merge a branch back into the trunk (assuming that you have an up-to-date working copy of the trunk):
svn merge --reintegrate https://mysvnrepo/svn/branches/myproject-branch-1.0
svn commit -m "Merge myproject-branch-1.0 back into trunk."
To merge changes to a single file:
svn merge -c 31 ^/trunk/myfile.txt myfile.txt
Merge between two revision revisions:
svn merge https://mysvnrepo/svn/branches/myproject-branch-1.0 -r103:HEAD