SVN-trunk/Branch
A large project in the development may be split into several small projects, separate, and the common part of the people to do, and then unify the merger. At the same time, in the development, the common part of the changes, others to keep in sync. This situation reflects the SVN branch/merge function, which is more appropriate. SVN can create a branch for the content (trunk) in a repository. The branch and trunk are completely independent, which is equivalent to copying the code and re-adding it to the repository. But SVN provides another function, which is to merge the changes from the trunk into the branch and merge the contents of the branch modifications into the trunk. Of course, we can also switch the path of the trunk repository to the branch and update it to update the branch changes to the trunk, and modify the branch path to synchronize the skeleton's changes. But the process is complex and error prone. The SVN branching feature also provides a number of combined tests that can be completed without altering the version path. Example:
1. Build a branch of an entire project.Note: 1. The current copy source, which is the "backbone (truck)" in the professional terminology 2. The location where the branch is stored. Of course, the branch is also in the SVN repository. 3. Write the log. 4. Whether to switch the trunk path to the branch. If the branch is selected, the update is submitted to the branch after it has been modified and submitted in the trunk. The version source content of the trunk does not change. When we look at the properties of the trunk directory, we can see that its path has become:/calc/branches/my-calc-branch.
To avoid confusion. and mistakes. Do not tick the "switch to branch" option when setting up. If it's hooked up, we'll switch back:
Note: 1. Trunk Directory 2. Repository Source Path
You can then develop new features on the/calc/branches/my-calc-branch branch without affecting the content of other members developing or maintaining the backbone.
2. Merging the trunk changesPerhaps after some time, the original/calc/trunk trunk may have been some other members have fixed some Bugs, but then your branch/calc/branches/my-calc-branch can directly apply the backbone (/calc/trunk) Update, In addition to avoiding duplication of effort, version conflicts can also be avoided because multiple people change the same file for possible conflicts. It is often a good practice to merge the changes of the development backbone (/calc/trunk) through the SVN merge to the branch (/calc/branches/my-calc-branch) so that you do not leave the trunk too long and cause the branch ( /calc/branches/my-calc-branch) when merging back to Trunk (/calc/trunk), there are many conflicts.
Merging from the trunk (/calc/trunk) to the branch (/calc/branches/my-calc-branch) is usually selected 1th, which is the [merge a range of revisions] note. We are the merge used on the branch function. Because it is the update to which the skeleton is to be applied on the branch.
In the merge window there are the following considerations: 1. The source of the merger, since we intend to merge from the trunk (/calc/trunk) to the branch (/calc/branches/my-calc-branch), so the source of the merger to choose/calc/trunk! 2. The results of the merger will be compared directly to the current "working directory" (working Copy) and modify all the files in the current working directory. It is therefore recommended that you commit all files that have not yet been commit to the repository before merging to avoid unnecessary conflict events.
Before you formally merge (merge), it is recommended that you execute the Test merge to see if anything happens! If the same can be done directly by pressing the [merge] button to merge the action, then from the backbone (/calc/trunk) branch out to the current working directory version will be a comparison, and then directly apply changes to your existing files, directories or attributes.
If there is no conflict after the merge, it does not mean that there is no conflict, so you must verify the original code again before you commit to the repository, it is recommended that you refer to the following process: 1. Build the project (build) 2. If you don't have a problem, unit test the project (Units testing) or manual test (Manual testing) 3. If it's all right, commit the current merge-error version to the repository!
3. Merging branches into the trunkFinally, our My-calc-branch branch has developed and tested the new functionality so that the final version of the branch (/calc/branches/my-calc-branch) is merged back into the trunk (/calc/trunk), as follows:
Merging from the branch (/calc/branches/my-calc-branch) back to the trunk (/calc/trunk) is usually the 2nd choice, and it is important to select the [Reintegrate a branch] option, as this has the following benefits: 1. Let subversion know which branch and which version of the trunk (/calc/trunk) is merged in 2. Effectively save Subversion Repository (SVN repository) space because you do not have to store all the change information for the Branch 3. Can produce Revi Sion graph learns about the branching status of project development
You can test the merge first and then formally merge (merge)
After merging, commit changes to Repository
4. Delete the Used branchWhen the branch (/calc/branches/my-calc-branch) is merged back into the trunk (/calc/trunk) and commits, the branch is useless, and if the branch is not updated or continues to develop in the future, Subversion will not continue to track the branch. (because it has been reintegrate before), it is recommended to remove the branch.
SVN-trunk/Branch
