SVN Trunk (trunk), Branch (branch), tags (tag)

Source: Internet
Author: User

Trunk, Branch (branch), tag (tag)

Branch/tag in SVN is often confusing in the use of a feature option.


On the implementation, branch and tag, for SVN are implemented using copy, so they are on the default permissions and the general directory is not different. As for when to use tag, when to use branch, completely by the human subjective according to the norms and needs to choose, rather than mandatory (such as CVS).

Under normal circumstances,

trunk: is used in the direction of the development of the development of a new module, this time on the trunk, when the module development is completed, need to modify, use branch. &NBSP
Branch: is used for parallel development, where parallelism refers to the comparison with the trunk.
Tag : is used to make a milestone, whether it is a release version, but is a usable version. Here, it should be read-only. More is a display, giving people a readable mark.

For example, 3.0 development is complete, this time to do a tag,tag_release_3_0, and then based on this tag to publish, such as the installation program. Trunk into the development of 3.1, but 3.0 found a bug, then you need to do a branch based on TAG_RELEASE_3_0 (branch), Branch_bugfix_3_0, based on this branch bug modification, until the end of Bugfix, Make a tag,tag_release_3_0_1 and then, as needed, decide whether the BRANCH_BUGFIX_3_0 is incorporated into the trunk.

One thing to note about SVN is that it is the global version number, which is actually a tag, so we can often see what the release is, based on the 2xxxx version of the XXX project. That's what it means. However, it also explicitly gives a tag concept, because it is more readable, after all, it is easier to remember tag_release_1_0 than to remember a large version number.

Branches: Branching
When multiple people work together, there may be situations where John suddenly has an idea that is not quite consistent with the original design, perhaps the addition of functionality or the improvement of the log format, all in all, the idea may take a while to complete, And in this process, some of John's actions may affect Sally's work, John from the existing state of a separate project, and not in time to get Sally to the code has been modified, and independent, John's attempt to succeed, with the original merge also has difficulties. At this point the best practice is to use branches. John builds his own branch, and then experiments in it, gets updates from Sally's trunk when necessary, or brings his own stage results into the trunk.
Command to create a branch:

(SVN copy sourceurl/trunk destinationurl/branchname-m "Creating a private branch of xxxx/trunk.")

Trunk: Trunk
Trunk, which is generally the main place of development,


Tag:: Tag
After a period of development, the project arrives at a milestone stage, and you may want to record the status of the code at this stage, then you need to tag the code.
To create a tagged command:
(SVN cp file:///svnroot/mojavescripts/trunk file:///svnroot/mojavescripts/tags/mirrorutils_rel_0_0_1-m "taged Mirrorutils_rel_0_0_1 ")

There is another saying that it doesn't matter who is right or who is wrong.

Trunk: Represents the directory where the version of the development is stored, that is, the code in the development phase is submitted to that directory.

Branches: Represents the directory where the published version resides, which is the stable version that is released when the project is launched.

Tags: represents the directory in which tags are stored.

In this need to explain the reasons for the next three directories, if the project is divided into one, two, three, and so on, then a stable version of the issue should be in the first phase of the completion of the code copy to branches, so that the two development of the code will not affect the first period of code, such as the new module will not be deployed to the and the stable version on the branches is published to the production environment code, if the user found a bug in the process, as long as the bug is modified on branches, modify the bug and then compile branches on the latest code published to the production environment.

The role of tags is to create a version ID when you merge the code of the bug that was modified on the branches into the trunk. Later, when the bug code modified on the branches is merged into the trunk, it is merged from version of tags to the latest version of branches to the trunk to ensure that the previously modified bug code is no longer merged.

-------------------------------------------------------------------------------------------

I've been using SVN just as CVS, and I've never read the documentation carefully until today, to look through the SVN book document, ashamed

Requirement One:
one customer wants to customize the product, but we don't want to modify the original code in the SVN trunk.
Method:
Use SVN to build a new branches, from this branche as a new starting point to develop
SVN copy svn://server/trunk svn://server/branches/ep-m "Init EP"

TIP:

If your svn has not previously branches this directory, only trunk this, you can use
SVN mkdir Branches
Create a new directory

Requirement Two:
Product development has been basically completed, and through very rigorous testing, this time we want to publish to customers, release our 1.0 version
SVN copy svn://server/trunk svn://server/tags/release-1.0-m "1.0 released"

Hey, what's the difference between this and branches, as if there's no difference?
Yes, branches and tags are the same, are directories, but we do not change the tag of this release-1.0, no longer submitted, if submitted so is branches

Three requirements:
one day, suddenly in the trunk of the core found a fatal bug, then all the branches must be the same, how to do?
Svn-r 148:149 Merge Svn://server/trunk Branches/ep

SVN Trunk (trunk), Branch (branch), tags (tag)

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.