Branch/tag of SVN

This section describes how to compare branch and tag in SVN. In SVN, branch and tag are often confused in a function option. In terms of implementation, branch and tag are implemented using copy for SVN, so their default permissions are no different from general directories. As for when to use tags and when to use branch, it is entirely subjective to choose based on specifications and needs, rather than mandatory (such as CVS ), next, let's take a look at the detailed introduction of branch and tag in SVN.

Comparison between branch and tag in SVN
In SVN, branch and tag are often confused in a function option. In terms of implementation, branch and tag are implemented using copy for SVN, so their default permissions are no different from general directories. As for when to use tags and when to use branch, it is entirely subjective to choose based on specifications and needs, rather than mandatory (such as CVS ).

Generally, a tag is used as a milestone. Whether it is release or not, it is a usable version. Here, it should be read-only. It is more of a display, giving a readable mark.
Branch is used for parallel development. parallelism here refers to comparison with trunk. For example, if 3.0 is developed, a tag, tag_release_3_0 will be created at this time, and then the release will be implemented based on the tag, such as the installer. Trunk enters the development of 3.1, but 3.0 discovers a bug. Therefore, you need to create a branch based on tag_release_3_0, branch_bugfix_3_0, and perform bugfix based on this branch. When the bugfix ends, create a tag, then, determine whether branch_bugfix_3_0 is incorporated into the trunk as needed. Note that SVN is a global version. In fact, this is a tag, So we often see what release is based on the 2xxxx version of the XXX project. That's what it means. However, it also clearly gives the concept of a tag because it is more readable. After all, it is much easier to remember tag_release_1_0 than to remember a large version number.

The Branch and tag creation methods in SVN are relatively simple. The operations in totoisesvn are:
1. Select branch and tag ..
2. fill in the URL in the tourl in the interface, which is generally SVN: // ip/project/branches/branch-1, so that a branch-1 is created. creating tags is the same, except that the URL is generally SVN: // ip/project/tags/Tag-1
3. The next createcopyfrom is used to select which version of your current workingbase to create branch and tag, which can be customized according to your choice. Generally, headrevision is selected.
Almost the same operation is performed in subclipse.

Merge is divided into many types:
1. merge between multiple Branchs
2. branchmerge to trunk
3. trunkmerge to Branch
There are more than 2nd types of applications. For example, after the requirement of netamount in the OTFs interface is raised, a netamount branch must be established. Trunk continues development without netamount. netamount is developed independently, after the netamount function is tested, run netamountbranchmerge to trunk and then trunkrelease. In the above example, if you do not want to test the netamount function, you need to modify merge in the trunk to netamountbranch, then, release a version from netamountbranch for testing.

Branch merge to trunk in tortoisesvn:
1. Select tortoisesvn-> merge
2. Select reintegrateabranch
3. Select fromurl. After the URL is filled, click showlog to check whether this branch is the content you want to merge. In workingcopy below, you can also run showlog to check whether your working directory is trunk. Click Next after confirmation
4. Some options in mergeoptions are selected as needed. The testmerge button will tell you what operations merge will do this time. It is best to test merge first! For the expected merge operation, click merge to add branchmerge to the local working directory.
5. Conflict files need to be resolved. After resolving the conflict, click svncommit to complete merge.

In the comparison between branch and tag in SVN, the operations from merge in multiple revisions to local working directory in tortoisesvn are as follows:
1. Select tortoisesvn-> merge
2. Select mergearangeofrevisions
3. urltomergefrom fill in the merge source. The merge source is generally different from your workingcopy branch, workingcopy is trunk, and mergefrom is branch.
4. revisionrangetomerge fill in the revision of merge in the format of 1, 3, 5, or 1-10.
5. Subsequent operations are the same as reintegrateabranch.

The merge operation performed by subclipse is different from that performed by tortoisesvn. The principle is basically the same as that of mergearangeofrevisions.
After you click "team"> "merge", there is only one interface, which provides two merge operations:
1. modify a version of merge to a local working directory.
2. mergefeaturebranch to trunk (merge to local)
The 1st methods are as follows:
1. Fill in the branch URL in fromurl.
2. In fromrevision, select to create the revision number of this branch. It is not the latest version number!
3. Check the checkbox "use 'from: 'url" in the tourl box. In torevision, select the revision number that requires merge. Generally, check headrevision.
4. dryrun allows you to preview the merge effect. unifieddiff performs diff on both sides of the merge and saves the diff result to the file. (In my machine, dryrun has no window, And the diff result file is too large unless there is only a small change)
5. click merge to synchronize merge to the local machine. At this time, the synchronization with the version library should have the same effect as the dryrun in the previous step. If the merge is not the expected change, you can select revert, however, the newly added files must be manually deleted! If it is the expected merge effect, commit. Remember to write branch, fromrevision, and torevision in merge comments (do not write head or number). In general, the merge operation of subclipse is not convenient, not as good as tortoisesvn. The comparison between branch and tag in SVN is complete.