Create Trunks, Branches, Tags procedures in SVN

About branches and tags in svn

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 a branches-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, which are mainly used in project development milestones, such as development to a certain stage can be a single version as a release, it often represents a full version can be fixed, the root of the VSS tag is roughly the same.

Branches and tags in svn are often confusing because the methods created in TORTOISESVN are consistent, and they are all created by storing a lunch shortcut like Linux, just creating a link to a version. Instead of actually copying this version of the content into a branch or tag, this saves space and can be created very quickly.

To facilitate the creation of branches and labels, we are accustomed to arranging the structure of the Repository repository as:/branches,/tags,/trunk. Represents branches, labels, 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.

1. Create a branch branch or tag tag

It is easy to create a branch and tag when the repository is created according to the recommended structure.
A repository test was created on my SVN server with the following structure:

In my local checkout checkout, add a file Test.txt and then commit.

Join this time we need to publish a version of the file, while there may be other people will be modified, but we can not affect the current file, only after its modification and then merge, in which case we create a branch.

This time we can find the URL of the SVN property of the local trunk folder has been switch to the address of the created version:

To perform the SVN update command, you can see the new folder under the Local Branches folder v1.0 and the file v1.0 inside the folder.

2. Modify the branch and use the merge merge feature

Modify branches/v1.0 The following file Test.txt, add a line modified in branch v1.0. Then check in to the SVN server:

Since we have just converted the SVN repository URL of the trunk to the corresponding version, we can see the updated Test.txt file at this time by updating the trunk folder.

For testing purposes, we switch the trunk folder to the corresponding trunk address:

When switch succeeds, we can see that the contents of the Test.txt file under the trunk are not changed, which is a reflection of what we have just said about the changes in the branch without affecting the trunk. Modify the Test.txt under the Trunk folder below to add a line modified in trunk. Then check in to the SVN server:

It is best to implement an important feature, merge merge, merging branches into the trunk, which is a feature we often use in team software development.
In TortoiseSVN's revision graph, you can view the version change diagram of the trunk as follows:

As you can see from the figure above, we created the branch version in version 10/branches/ v1.0, and SVN version is 11, on the basis of version 11 we have modified the branch and then we have version 12, we have to modify the file under the trunk and then have version 13, the entire SVN current version is 13, which is consistent with the changes we just made.
The following merges the branch v1.0 into the trunk.
According to our current situation, choose the second type:

Select v1.0:

Then, as follows:

There's definitely a problem in our merger, Since we have made two modifications to the Test.txt file, which results in conflicting conflict, this should not be the case in practice, since the branch is created to modify files that are not modified in the trunk so that the modifications are merged into the trunk after completion. But it doesn't matter, we're only here to demonstrate, so just deal with the conflict, manually merge it (which in practice should not otherwise have lost the use of the branch):

This time you can see that our Test.txt file has been implemented as I have just manually handled the conflict:

Then check in the trunk into the repository:



If you look at the Test.txt file under branches\v1.0, it's still content that was originally edited in the trunk.
Another point of emphasis: in the actual operation we will not be a branch file in the trunk of the changes, otherwise there will be some conflicts, so that the convenience of the branch is lost; tag creation and branching is the same as the class S, but tag is often used only to identify a specific version, but not for bug fixes, Add new features and more.