SVN merge and branch Analysis

[Reprint]

I have been using SVN for a few years and have always kept a close eye on branch and merger. First, it is because branch management should not be concerned with me. Second, even if branch management is involved, I am afraid to use the Merge function rashly, for fear that the merger will cause adverse effects on the team, the main reason is that you do not know much about the purpose and merger methods of the branch, which is hard to hurt.

 

Recently, due to the need to adapt models (I am engaged in the development of mobile phone clients), I often need to come into contact with branch and merge jobs. I suddenly found this stuff hard to work, I 've focused on my research over the past two days. I'm afraid I will forget it later, so I'm still writing it down. It's better to remember it. The following practices mainly refer to tortoisesvn help documentation and subversion of online documentation, subversion of online documentation: http://svnbook.red-bean.com/en/1.5/svn-book.html

 

The source code management in our company is quite messy. The SVN directory does not adopt the standard source/branches, source/trunk structure, and the main line and branch are stored at the same place, the release version is not processed as a tag, but managed as a branch. It is often changed in the release version...

 

Let's talk about Branch first. According to the subversion, a branch is a copy of a certain development line (usually the main line, that is, trunk). For details, see:

 

The significance of branch lies in that it is developed in parallel with trunk without interfering with trunk, and merged back to trunk after the development is complete. During the development process of branch and trunk, they can constantly submit their own changes, so that each change has a record in the repository.

 

Imagine the following scenario. If your project needs to develop a new function that may modify the vast majority of files in the project, and at the same time, another colleague of yours is fixing bugs, if your new features are not developed in Branch but are directly developed in trunk, you are very likely to affect the bug fix of another colleague, he/she may encounter various problems in bug fixes, because your frequent code submission introduces too many unstable factors. You may say that I don't need to submit it during the development process. I will submit it after all my development is complete. Yes, you can do this, what about version control? Maybe wait until you finally submit the code (maybe one week, maybe two weeks ?), You will find a lot of conflict waiting for you to resolve...

 

So what is the correct approach? Use branch to create branch from trunk, develop it on your branch, and merge it into trunk after development.

 

For branch, let's talk about merge. It is easy to understand that when branch completes development (including necessary tests) and synchronizes the modifications in branch to trunk, this process may include modifying files, adding files, and deleting files.

 

Speaking of this, it seems that this article is almost over. Isn't it about Branch and merge? You just need to briefly talk about how to create a branch and how to merge it. You may only need two commands or just a few mouse clicks and double-click the keyboard. In fact, it is far from that simple, and some people may ask, when we change branch's merge to trunk, what is the difference between it and the above-mentioned direct development and submission in trunk? Are you still dealing with a lot of conflict?

 

This is actually the focus of this article: How branch and trunk perceive each other during parallel development, how can branch not move farther and farther along with trunk during development, resulting in the final failure to merge? Imagine if, during your branch development, A class file in trunk has been deleted (it may be that another guy has been developing on another branch for two weeks before it is merged to trunk ), and you have made a lot of changes on this class file. How much trouble should you try to merge it back to trunk? The only way to solve this problem is to keep branch in sync with trunk. You need to know in time what changes have been made by trunk and whether these changes will affect the new features you are developing, if necessary, you must promptly adjust branch code to make it "compatible" with trunk ".

 

So how can we keep branch and trunk synchronized? Merge: merge from trunk to branch. You didn't hear the error. It was merged from trunk to branch. Note the following when merging tortoisesvn:

• Tortoisesvn merge occurs locally, that is, in your working copy. You don't have to worry too much about the impact on the code in repository.

• Whether merged from trunk to branch or finally merged from branch back to trunk, it is best to update before each merge, and then all the local modifications are committed first to protect the site, revert can be used at any time if merging is not ideal.
• After merging, check whether the compilation is correct, test and verify, and finally submit the merged changes to repository.

 

 

Next I will demonstrate step by step how to complete branching and merging, including creating branches, branch development, branch and main line synchronization, and merging branches into the main line, it even includes how to create a repository for testing locally.

 

First, install tortoisesvn. The installed version is tortoisesvn 1.6.15, build 21041-32 bit, 18:00:27

 

1. Create a local repository

The repository creation is simple. If you want to create a repository in the D: \ tortoisesvn \ testrepository directory, right-click the testrepository directory, select tortoisesvn> Create repository here to create a repository.

 

2. Check out

If you want to check out to D: \ tortoisesvn \ testsvn, it is also very simple. Create the testsvn directory under the D: \ tortoisesvn directory, right-click the directory, select "SVN check out... ", in the pop-up window, enter" file: // D:/tortoisesvn/testrepository "in" URL of repository ". Click" OK.

 

3. Trunk creates a new project myproject

I will not go into details in a simple way. I will only list the modifications made in this operation:

 

4. Create Branch

Right-click the/trunk/myproject directory and choose tortoisesvn> branch/tag... ", fill in the Branch Address in" to URL "in the pop-up window. Here, select head revision for the target revision, as shown in. After adding the log, click OK to create the branch. This operation is very fast. The new branch is actually a soft connection pointing to a revision of the trunk in the repository, and does not really copy files.

 

5. Check out Branch

Right-click the testsvn directory and select "tortoisesvn Update" to download the created branch back to the local device. Enter the/branches/myproject directory and you will find that the file structure is exactly the same as/trunk/myproject.

 

6. submit a new file through branch.

 

7. Trunk then submits a change

 

8. Submit another change for branch.

 

9. Synchronize the changes in trunk to Branch

6-8 demonstrates independent and parallel development of branch and trunk. To prevent moving farther and farther along the "wrong" path, branch now realizes that it is time to synchronize with trunk (merge trunk into branch ).

First, update the trunk in the local trunk to resolve the conflict. Ensure that the trunk and repository are fully synchronized, and right-click/branches/myproject, select tortoisesvn> merge... ", select the first item" merge a range of revision "in the pop-up window. This type of merge has been described clearly, it is applicable to merging changes between multiple revisions submitted on a branch or main line to another branch.

 

Click next and the following window appears:

 

Because it is to merge from trunk to branch, the "URL to merge from" here should fill in the trunk path, "revision range to merge" is easy to understand, that is, you need to merge the changes corresponding to the revision of the trunk into branch. It can be a series of revision, such as 4-7,15-head, or a separate revision number. Since the trunk modifies the talk () method in person. Java in R4, only 4 is required for revision. Click Next:

 

Here, you only need to retain the default settings. Before clicking the merge button, you can test merge first to check whether it is successful or not, and the merge details. Click the merge button and the changes made by trunk will be synchronized to branch.

 

10. Submit the merged Branch

 

At this point, Branch has been fully synchronized with trunk, and branch and trunk code are very well-formed and there is no conflict. If Branch has been developed, it is time to merge branch back to trunk. Of course, if branch needs to continue development, you will continue to repeat the steps 6-10.

 

11. Merge branch back to trunk

Right-click/trunk/myproject (Note: Right-click the main line Directory) and choose tortoisesvn> merge... ", in the pop-up window, select the second item of merge type" reintegrate a branch ", which is suitable for merging all the changes back to the main line after branch development.

 

Click next and the following window appears:

 

Here, "from URL" selects/branches/myproject, without the need to select the revision number, reintegrate will merge all the modifications on Branch to trunk. The subsequent steps are the same as those in step 1. If there is no accident, branch will be successfully merged into the trunk. All you need to do is to merge the merged trunk into the commit!

 

12. The merged trunk is submitted.

So easy...

 

13. Delete Branch

If you think that your new feature has been developed, you can delete your branch.

 

 

Here, I have already demonstrated the whole process for you, and my sweat is also down. I want to strike, but at last let's take a look at all the log information, log can be used to discover all the things we do:

 

The r1-r7 is exactly what I did above, from the message you can find out what I did to trunk and branch, and, in the lower left corner of the log messages window, select "include merged revisions". You can also see the additional merge information:

 

In the gray figure, there are two merge logs related to merge. The first is in R6. In R6, branch merges the changes submitted by trunk at R4; the second is in R7. In R7, trunk merges all branch changes from R2 to R6.