Detailed usage of tag branch trunk in SVN Conversion

Detailed usage of tag branch trunk in SVN

This article briefly introduces the usage of tag branch trunk in SVN. In SVN, tag branch trunk belongs to SVN sub-commands. How do they use it? This article will explain it to you one by one.

 

This section describes how to use tag branch trunk in SVN, in SVN, branch/tag is often confused in a function option. Here is a brief introduction. You are welcome to join me in learning the usage of tag branch trunk in SVN.

in terms of implementation, branch and tag are implemented using copy for SVN, therefore, 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, 3.0 is developed. At this time, a tag, tag_release_3_0, is created and then implemented based on this tag.
release, for example, install the Program . Trunk enters the development of 3.1, but 3.0 discovers a bug. Therefore, you need to create a
branch and branch_bugfix_3_0 Based on tag_release_3_0. Perform the bugfix based on this branch and wait until the end of the bugfix, create a
tag, tag_release_3_0_1, and then decide whether branch_bugfix_3_0 is incorporated into the trunk as needed. One thing to note about SVN is that
is that it is a global version number. In fact, this is a tag, So we often see what release, based on the 2xxxx version of the XXX project. That's what it means. However,
yes, it also clearly defines the concept of a tag because it is more readable. After all, it is much easier to remember tag_release_release_1_0 than to remember a large version number.

Branches: Branch
Tag branch in SVN
First, let's take a look at branches. When multiple people work together, John suddenly has an idea that is not consistent with the original design and may be functional.
Adding or improving the log format. In short, this idea may take some time to complete. In this process, some John operations may affect Sally's work.
In some States, if a project is created separately, you cannot obtainCodeIf John's attempt was successful, there was a problem with the original merger.
Difficult. In this case, the best practice is to use branches. John builds his own branch and then labs in it. If necessary, he gets updates from Sally's trunk,
Or you can collect the results of your own stages into trunk.

(Svncopysourceurl/trunkdestinationurl/branchname-M "creatingaprivatebranchofxxxx/trunk .")

Trunk: Trunk
The backbone is generally the main area of development,

Tag: icon

After a period of development, the project has reached a milestone stage. You may want to record the status of the code at this stage, so you need to tag the code.

(Svncpfile: // svnroot/mojavescripts/trunkfile: // svnroot/mojavescripts
/Tags/mirrorutils_rel_0_0_1-m "tagedmirrorutils_rel_0_0_1") also said, it doesn't matter who is right and who is wrong.

Trunk: indicates the directory where the version is stored during development, that is, the code in the development stage is submitted to this directory.

Branches: indicates the directory where the released version is stored, that is, the stable version released when the project is released is stored in this directory.

Tags: the directory where tags are stored.

In this case, we need to explain the reasons for dividing the project into three directories. If the project is divided into Phase I, phase II, and phase III, the stable version of Phase I should copy the code to branches when phase I is completed.
The code developed in phase II has no impact on the code of phase I. Newly Added modules will not be deployed in the production environment. The stable version on branches is the Code released to the production environment.
If a bug is found during use, you only need to modify the bug on branches and then compile the latest code on branches and release it to the production environment. Tags
The function is to combine the code of the Bug modified on branches to the trunk and create a version ID. When the bug code modified on branches is merged to the trunk
From the version of tags to the latest version of branches to the trunk, so as to ensure that the bug code modified earlier will not be merged.

Bytes -------------------------------------------------------------------------------------------

When introducing the usage of tag branch trunk in SVN, SVN has always been used as CVS, and I have never carefully read the documentation until today. I am ashamed to go through the svnbook documentation.

Requirement 1:

One customer wants to customize the product, but we do not want to modify the trunk code in the original SVN.

Method:

Use SVN to create a new branches, and use this Branche as a new starting point for development.

Svncopysvn: // server/trunksvn: // server/branches/EP-M "initep"

Tip:

If you have no branches directory in SVN, you can use

Svnmkdirbranches create directories

Requirement 2:

Product development has been basically completed and passed strict tests. At this time, we want to release our 1.0 version to our customers.

Svncopysvn: // server/trunksvn: // server/tags/release-1.0-m "1.0 released" done, what is the difference between this and branches, it seems that the difference is no?

Yes, branches and tags are the same. They are all directories, but we will not modify the release-1.0 tag and will not submit it any more. If yes, it will be branches.

Requirement 3:

One day, a fatal bug was suddenly found in the core of trunk, so all branches must be the same. What should I do?

Svn-r148: 149 mergesvn: // server/trunkbranches/EP where 148 and 149 are the versions of the two modifications. The usage of tag branch trunk in SVN is described.