Resolving version conflicts-using the SVN trunk and branching features

Resolving version conflicts-using the SVN trunk and branching features

1 Preface

Most product development has such a lifecycle: coding, testing, publishing, and then repeating. This is usually the development step:

1) After the developer has developed a version (such as version a) function, submit the test;

2) The tester treats release version A for testing, while the developer continues to develop new features (such as version B);

3) The tester submits the bug, the researcher fixes the bug, and continues to develop new features;

4) Repeat the 3rd step until the release of release a test passes test, release the first version

This has the following issues:

1) How to isolate a pending release version A from the code base (A+B) for testing and publishing;

2) If you are hosting a release version A, the development group must maintain both this repository A and the current code base (A+B), which is redundant and error-prone.

In SVN, the main trunk (trunk) and branch (branches) approach is often used to solve these problems.

2 Related concepts and principles

When you create a codebase in SVN, you usually create trunks, branches, tags, three subdirectories, and of course, you can use other names to implement the functions of the trunk and the branch.

trunk-trunk, or the main line, as the name implies, is the main line of development.

branches-branches, which are separated from the main line, are separate from the mainline of the other lines. You can create multiple branches. A branch always begins with a backup of the trunk, starting there, developing its own unique history (as shown). In a version-controlled system, we often need to make separate changes to the individual lifelines in the development cycle, a separate development lifeline that can be called branches, or branch. Branches are often used to add new features and bug fixes after a product is released, so that the main product development lines are not affected and compile errors are avoided. When the new features we added are complete, you can merge them into the trunk.

tags-tags, mainly used in project development milestones, such as development to a certain stage can be a separate version as a release, it often represents a full version can be fixed. That is, both the trunk and the branch are used for development, and the markup is used for phase release. Security Company's configuration library has a dedicated publishing area, so tags do not need to be created, here just provide instructions, not recommended to use.

Branches and tags are consistent in the way they are created in TortoiseSVN, all by storing a lunch shortcut like Linux, just creating a link to a version without actually copying the content of that version into a branch or tag. This saves space and can be created very quickly, known as "cheap copies."

To facilitate the creation of branches and tags, it is often customary to lay out the repository repository structure as:/branches,/tags,/trunk. Represents branches, markers, and trunks, respectively.

It is also worth noting that SVN does not recommend revision on the created tag, which applies branches because tag is generally unchanged and does not make any changes.

3 Branch management policy for code

There are two main types of branching and publishing strategies for code management: one is the backbone as a new feature development thread, and the branch is used for publishing. The other is the branch used as a new feature development, the backbone as a stable release.

3.1 Branches for publishing

The typical operation steps are as follows:

1) The developer submits all the new features to the trunk. Daily changes are submitted to/trunk: new features, bug fixes and others.

2) This trunk is copied to the "Pending" branch. When the team thinks the software is ready for release (for example, version 1.0) then/trunk will be copied to/branches/1.0.

3) The project team continued to work in parallel, a team began to perform rigorous testing of the branch, while the other team continued with new work in/trunk (for example, Prepare 2.0), and if a bug was found at any one location, the bug fix would need to be shipped back and forth. However, this process can sometimes end, for example, the branch has been "stalled" for the final test before release.

4) The branch has been marked and released, and when the test is finished,/branches/1.0 as a reference snapshot has been copied to/tags/1.0.0, which is packaged and released to the customer.

5) Branch maintenance multiple times. When continuing to work on/trunk for version 2.0, bug fixes continue to be shipped from/trunk to/branches/1.0, and if sufficient bug fixes have been accumulated, management decides to release 1.0.1 version: Copy/branches/1.0 to/tags/ 1.0.1, tags are packaged and published.

The whole process repeats itself as the software matures: When 2.0 is complete, a new 2.0 branch is created, tested, tagged, and eventually released, after many years, the repository ends with many releases, enters the "maintenance" mode, and many tags represent the final release.

This branch management strategy is widely used in open source projects. For example, the release of FreeBSD is a typical example.

The backbone of FreeBSD is always current, which is an unstable version that includes all the latest features. Then, with the gradual stabilization of the new features, a stable branch is separated from the backbone after reaching a release milestone. FreeBSD is a branch of each large version. That is to say 4.x,5.x,6,x each branch. Only bug modifications and existing features are available on each publishing branch, and no new features are added. New features will continue to be developed on the trunk. When the changes that occur on the stable branch accumulate to a certain extent, they are released once. A release branch is then distributed on the stable branch when it is released. Take 6.x as an example, there will be 6.0,6.1,6.2 ... and other publishing branches.

This publishing method is ideal for release management of product lines. Products are to be sold, the previous version sold to customers still need to continue to maintain, and for the future market, new features are constantly increasing. This management method isolates the maintenance of released products and the development of next-generation products. For products that have already been released, only maintenance patches are released. The newly released product includes not only all bug fixes, but also new features.

This approach has the following drawbacks: First, you must control the addition of new functions on the trunk. You can only add new features that you plan to integrate into the next release. Also, any of the new features that have been integrated on the backbone, if not required by the milestone, cannot be created by the stable branch, which is likely to affect the next published plan. Open source projects may be less stressful, but commercial product development is dangerous if it comes to this. Another drawback is that the bug modification must be merged between the various branches. From some practical experience of branching and merging, it is necessary to merge periodically between the branches that exist for a long time, otherwise it is easy to initiate merge conflicts. But the stable branches and the release branches happen to be unable to merge and exist for a long time. As a result, the biggest problem you might encounter with this branching strategy is the conflict that occurs when a bug on one branch changes its contents to another branch of the merge. And once a bug is found, investigating how the bug affects which branches will increase as the number of published branches is maintained.

In non-product development outsourcing software projects, the benefits of this publishing method are not reflected, but the shortcomings still exist. The outsourcing project is characterised by the customer always needing "up-to-date" code, so the maintenance of a branch that has already been released is rarely seen (when tested). And the release of the method and the release of the product is not the same. The release of the product, as long as the code on the release branch is compiled into an installation disk, and outsourcing is often the release of the last release and the release of the changes between the code to send to the customer. If each release is a branch, there will be a comparison on two branches. The powerful version control tool certainly supports this comparison, but many version tools do not support comparisons between branches, and only support comparisons between different versions within a branch. Therefore, in order to avoid the release method is limited by the tool, it is necessary to avoid the situation of inter-branch comparison. For the special case of outsourcing development, only another branch management strategy is adopted.

3.2 Backbone for publishing

In contrast to the first branch strategy, the trunk is always a stable version and can be released at any time. Bugs are modified and new features are added, all on the branch. And each bug and new feature has a different development branch, completely detached. Each release on the trunk is labeled rather than branched. The development and testing on the branch is completed before merging into the trunk.

The benefit of this publishing approach is that the content of each release is easier to adjust. If a new feature or bug cannot be completed before the next release, it is not possible to merge into the trunk, and it will not affect the release of other changes. In addition, the lifetime of each branch is relatively short, the only long-term existence is the trunk, so the risk of each merger is very small. Before each release, you will be able to know the scope of this release as long as you compare the latest version on the trunk and the last released version.

This release pattern also has drawbacks. If a development branch is not merged to the trunk for a long time because it is more complex or should be published, it is likely that there will be a conflict at the end of the merge. It is therefore important to keep an eye on the time when branching leaves the trunk. If some branches do exist for a long time because of the special needs, it is necessary to merge the trunk updates to this branch on a regular basis. To reduce the number of occurrences of this merge, and to limit the scope of the merge, to pre-establish a publishing branch for each release, then all the development branches are merged with each publishing branch according to its own release schedule. After all the changes have been integrated on the next branch of the release and the test is complete, merge the publishing branch into the trunk, release the trunk, and lock or delete the branch. Then merge all the updates on the trunk into the following release branches. The release cycle of outsourced projects is generally relatively short, often customer acceptance testing cycle is the release cycle. So this method is enough. If the release cycle is long, the various publishing branches are periodically merged from front to back. One drawback to this publishing approach is testing. Unlike the first branching strategy, the branch that is published is the branch of the test. The test branch of this release pattern is often the individual publishing branch, which merges the updates from the next release branch into the trunk before it is officially released, introducing the risk of merging errors, and the programs on the trunk are not tested. Fortunately, from this release mode, the merge base of the next publishing branch should be the same as the one in the trunk, so the risk of introducing merge errors is low. Another suggestion is to not set up the trunk, the next release branch is the backbone, directly publish the next release branch of the changes, and then merge the changes to the next release branch up. And so on

3.3 Precautions

1) When doing branch development, you must periodically synchronize the branch with the backbone to avoid serious conflicts (Confict) when merging (merge) back to the trunk when the development is complete;

2) before merging, dispose of all local modifications on the working copy to facilitate the rollback (revert) when the merge fails;

3) When merging, pay special attention to the new/delete operation, because many conflicts are caused by this kind of operation;

4) After completing the function of a branch and merging it back into the trunk, discard the branch and use the new branch for the subsequent development of other functions. Of course, there are ways to continue using the branch;

5) Auxiliary documentation is required. In order to observe the process of creating and merging branches, at least one document similar to the Swimlane diagram is required to mark each branch creation and merging process;

6) The number of times that the development branch is merged into the trunk or the publishing branch should be as few as possible. In general, the monomer test should be merged into the trunk or the release branch, and then tested together. If the combination test found that the bug should not be on the original development Branch to continue to modify, but should create a new branch to modify;

7) The log for branch creation and merging must be canonical. Easy to find later. The basic log information should include which version of the branch from which to create the branch, which branch from which version to which version of the change is merged to which version of which branch, the combined version number. Some of this information can be easily found by the version Control tool itself and can be omitted

4 Operation Steps

Create trunks, branches, tags directories in the code base, which are trunk, branch, and tag, for a clearer distinction between the main lines, branches, and tags. Create a branch when you submit code on the trunk to a level that can be published.

To facilitate comparison, we upload a file in the Trunk Readme.txt (version 659):

4.1 Creating a branch (TAG)

Check out the trunk trunk (checkout) to local, right-click on the local checkout trunk directory and select "TortoiseSVN" → "Branch/tag ..." from the pop-up menu.

In the pop-up window, point "to URL" to the branches directory and enter the specific directory name of the branch. The default destination URL will be the source URL of your current working copy, and you must edit a new path for the branch/tag. SVN does not automatically create a directory recursively, so you create a parent directory yourself first. For example, if you want to create a branch/branches/v1.0, then V1.0 can not create it yourself, but/branches to create it first. Here is branches/v1.0, the branch we are about to create is stored here, click OK

In the red box, create copy revision in the Repository option:

U HEAD revision in the repository: Copies the latest version in the current trunk. There is no need to transfer any data from your working copy, and the establishment of this branch is very fast.

U specific revision in repository: Copies a specified version of the trunk. It would be useful if you forgot to make a mark when you released the project last week. If you can't remember the version number, click the right mouse button to display the version log, and select the version number from here. As with the last time you don't need to transfer any data from your working copy, this branch builds up very quickly.

U working copy: The new branch is a copy that is exactly equivalent to your local working copy. If you update some files to an older version of your working copy, or if you make changes locally, the changes will be correctly entered into the copy. Naturally, this comprehensive tag contains data that is being transferred from the working copy to the repository, if that data does not already exist.

When you have finished selecting and clicking the OK button, the branch is created. Looking at the configuration library again, you can see that the branch you just created includes the document "Readme.txt" in the trunk, which is version 659, consistent with the trunk.

tags are created in the same way as branches, which are copy operations to the trunk (which is actually a link to a version).

4.2 Merging Branches

Branches are used to maintain separate development branches, and in some stages you may need to merge the changes on the branch to the latest version or merge the latest revisions into the branch

To facilitate comparison, we modify the Readme file in the branch (at this point, version 664) and add a file:

If you want to merge the branches onto the trunk, right-click on the local checkout trunk directory and select "Tortoisessvn" → "merge" from the pop-up menu

Select a category from the "Merge" menu that pops up:

Select the URL of the branch in the URL to merge form input box, and in the "Reverse Range to merge" fill in the version, click the "Show Log" button to select the version you want to merge. It is important to note that merge does not literally merge two branches together, but rather diff-and-apply, comparing the differences of two branches and merging the differences. Click "Next" when you are finished typing:

After selecting the merge option (such as "Compare whitespaces"), click "Merge" to complete the merge operation.

If a conflict occurs during the merge process, SVN will prompt you:

After merging, the following files are displayed in the local trunk directory:

There is an exclamation mark in the conflicting file icon, and the system automatically generates 3 files:

U Readme.txt is the version in the trunk before merging

U readme.txt.merge-left.r.664: Version 664, that is, in the trunk when the branch is created

U readme.txt.merge-right.r665: Version 665, that is, in the previous branch of the merge

You can directly open the file for manual modification, the conflicting content will be negotiated <<<<<<<............>>>>>>> identified

You can also select the file, right-→tortoisesvn→edit the Conflicts,tortoisemerge window to display conflicting file comparisons, which you can edit in the merged dialog box:

After the modification, right-→tortoisesvn→resolved, the system automatically generated 3 files will be automatically deleted, the conflict file icon will become uncommitted status, right-→SVN commit, submitted to the configuration library.

When you have multiple files conflict, you need to resolve each.

If the merged content is not satisfied, you can cancel the merge operation by undoing it, provided that the merged file is not committed.

Summarized as follows:

1. If you need to merge the branch changes into the main line, you need to merge under the working copy of the main line, the scope of the merge is to need to be from the last merged version on the branch to the latest version on the current branch, if the mainline and branch have modified the same file, the merge will conflict, then resolve the conflict, commit, Then the starting version number is the version number of the last branch established;
2. Conversely, if you need to merge the changes of the mainline into a branch, you need to merge under the working copy of the Branch, the scope of the merge will need to be from the last consolidated version on the main line to the latest version on the current mainline, conflict after the merge (as in the case of the conflict), and then resolve the conflict if the mainline is modified but , the merged changes on the main line are added to the current copy, committed, and, if the first merge, the starting version number is the last branch build

The work of merging is to list all the changes in the merge scope of the main line or branch, and to compare the contents of the current copy and manually modify the conflict by the Consolidator. If the current working copy is the main line, the merge scope is a change on the branch, and if the working copy is branched, the merge scope is a change on the main line.

Resolving version conflicts-using the SVN trunk and branching features