SVN branch merge

Http://blog.163.com/lgh_2002/blog/static/4401752620106202710487/

Subversion branches are usually used in the trunkProgramTo modify the program. In this way, you can try to study and modify new functions without disrupting the development, testing, and release processes of the main program. If you think there is no problem with the new features, you can merge the branches into the main program.
Before merging, You need to submit the branch (COMMIT). In this case, the merge operation is similar to the operation performed at the same time on the server and the local client.
When merging, you need to start from the right-click menu of the master's working copy. "from" url is the merged destination. You need to select the main URL, and "to" is the source of the merge, select the branch URL.

SVN's merge is actually very useful. Of course, the premise is that you understand the svn merge command. Fortunately, I used it for about a year to understand this command -___-!!

Let's talk about the usage. For example, we want to take the branch merge to the trunk.

# SVN merge --Helpmerge: Apply the differences between two sources to a working copy path. Usage:1. SVN merge sourceurl1 [@ n] sourceurl2 [@ M] [wcpath]2. SVN merge sourcewcpath1 @ n sourcewcpath2 @ M [wcpath]3. SVN merge [-c m |-R n: m] source [@ rev] [wcpath]
 

Let's take the first example:
SVN merge sourceurl1 [@ n] sourceurl2 [@ M] [wcpath]
The help prompts that merge requires three parameters.
Sourceurl1 and sourceurl2 do not mean two branches or one trunk, but represent two States or two versions of the same branch, then, apply the diff result to the final wcpath parameter. wcpath indicates a local work zone that has been checkout.

The idea of SVN merge is: diff and apply

 

For example, I developed a project called proj.
The directory structure is
Proj/trunk
Proj/branches
Proj/tags

(After saving http: //, it is only a relative path, but it cannot be omitted in actual use)
When the version reaches 100, I decided to do a branch for some other development:

 
[Reversion:100] $ SVNCPProj/trunk proj/branches/Proj_branch_1ok reversion:101
 

Then, trunk and proj_branch_1 are both under parallel development. In a specific version, such as 150, branch is developed successfully, and merge needs to return to trunk.

The directory structure is
[Reversion: 150]
Proj/trunk
Proj/branches/proj_branch_1
Proj/tags

According to the implementation of SVN, I need to know all the changes made by proj_branch_1, that is, the changes in the current status of the branch compared to the status just generated (SVN CP, generate a diff file based on this change and apply it to a local workspace. (A Clean local trunk work zone is recommended)

Then execute:

 
$ CD proj/Trunk $ SVN merge proj/Branches/proj_branch_1 @101Proj/branches/proj_branch_1.
 

In fact, the first URL (we call it the left side) is in the starting state. The last @ 101 indicates that the version 101 is used,

This version 101 is the version after successful svn cp. The second URL (we call it the right) is the final state, and the latest URL is used by default,
There is a diff on the left and right, which is applied to the current workspace directory, that is, trunk.
Now, you can see the changes in $ SVN St.

The question here is how to obtain the version after the CP, that is, 101 in the example.
You can use the -- stop-on-Copy command in SVN log

 
$ SVN log -- stop-on-copy proj/branches/proj_branch_1
 

The screen stops at CP, where the marked version is the required version.

For example, the following is a real example:
Bytes ----------------------------------------------------------------------------------------------------------------
R995 | lgh | July 20 09:25:10 + 0800 (1, 19 August 10) | 1 line

Create a branch for proj client using
Bytes ----------------------------------------------------------------------------------------------------------------
R995 and 995 are the versions I need.
(To explain the benefits of writing comment during commit, for example, I am sure this is the initial version of branch)

Other usage of SVN merge is similar. You only need to understand that diff is generated on the left and right, and then applied to a local workspace.

You can also use SVN merge -- dry-run to simulate merge and see what will happen to merge instead of doing this.

For the help of merge

3. SVN merge [-c m |-R n: m] source [@ rev] [wcpath]
This is also easy to understand, that is, the difference between source and version n and M is used in the local work zone of wcpath.

Note!
Do not perform branch based on the locally modified workspace. It must be based on the version of a URL. Diff does not come out during diff, because it is based on the local workspace, so now merge is very difficult.