Been tossed with svn branching and merging for two days. Just now I finally solved the problem of branching and merging, and the packaging and deployment were successful. Summarize so as not to forget. Some time ago, the project was branched from the svn trunk because it wanted to join the OSGi blueprint method to publish and obtain services. Now that the development of the branch is complete, it is required to be merged into the trunk. The directory structure of svn is as follows:
Trunk trunk:
https://192.168.0.11:8443/svn/code/product/trunk/project-name/code/OSGiServer/plugins/com.tzf.svn.test
tag：
https://192.168.0.11:8443/svn/code/product/tag
Branches:
https://192.168.0.11:8443/svn/code/product/branches/project-name/code/OSGiServer/plugins/com.tzf.svn.test
First download the win2svn file from http://subversion.apache.org/packages.html#windows : Setup-Subversion-1.6.13. To install, under cmd, the svn command is fine. Downloading this does two things: viewing the version when the branch was forked and resolving merge conflicts.
Here I am merging from branch to trunk,
Operands: Trunk
From : The version of the trunk when the branch was made
To: Head version of the branch (latest version)
How to understand this From and To ? It seems to be different from what we think: because we understand that when a branch is merged into the trunk, it must be the From branch and the To trunk. How did it go wrong?
In fact, Svn believes that what we want to merge is to start from a certain version of the trunk and end with a certain version of the branch. The version numbers on both sides are actually a set of systems, and there will be no repetition.
For example, the structure of my backbone is as follows:
Now make some changes in the branch, for example, I add a class called Bean2.java, and submit it. As shown in the figure:
Well, now switch the project to the trunk, because the branch is merged into the trunk, and the operated object is the trunk project.
To merge to know the version number when the branch is split, cmd opens the command line and uses svn log --verbose --stop-on-copy branch_path to view the version update information, as shown in the figure:
Find the bottom version information, here is r8623, remember this version number, and the merged from will start from this version number. to refers to the version number you want to merge, usually the latest version, of course, it can also be a specified version.
Switch to the trunk, select the project, right-click team -> merge:
next, appear
From is the path of the branch. The version number selected below is the version number of the branch that was just written down. To here is the latest version to be merged into. Click finish, if there is a conflict in the file, a query box will pop up, and you can choose not to process it for now.
I have no file conflicts here, just click ok and you are basically done. At this time, you need to check the files with modified symbols in the trunk, and the merge is done after the submission is completed.
What should I do if the files conflict, enter the directory of the conflicting files under the command line, and use the svn command line client to type: svn resolved conflicted filename to resolve the conflict.
Well this is a merge from branch to trunk. There are also two types of merges: from trunk to branch and from branch to branch, and the operations are similar. The specific reference is as follows:
Merge from trunk to branch
Imagine this situation: In a project, to separate a sub-project, a separate version needs to be released, the basic framework code is used, and the basic framework is constantly modified and improved in the trunk, which requires merging from the trunk to the branch.
Operated object: branch
From: the first version of the branch (oldest version)
To: Head version of the trunk (latest version)
It is equivalent to replacing the branch from the first version of the branch to the end of the last version of the trunk after the merge.
Merge from branch to branch
There is such a requirement: there are many branches in a project, and these branches need to be launched in stages, and there are multiple tasks in parallel, but each stage cannot affect each other, so several tags (also branches) can be typed, copied from the trunk and Come. Other trunks are merged into these tags according to the schedule. For example, there are prjTag1 and prjTag2, model1 and model2 need to be merged into prjTag1, and model3 and model4 need to be merged into prjTag2. Take prjTag1 as an example:
In the work copy of prjTag1, merge
From : The version of the trunk when the branch was made
To: Head version of the branch (latest version)
Note: From is not a version of this Tag, but the version of the previous trunk when the branch was branched, and finally merged to the work copy of prjTag1, and prjTag1 could not find the version when the branch was branched.
After being merged by svn for two days, there may be a reason for the complexity of OSGi. The problem is solved, but it is also very cumbersome. Hope to see a better way to share with friends and friends.