Reproduced SVN trunk, branch, Tag usage

Subversion has a very standard directory structure, which is the case.
For example, if the project is PROJ,SVN address svn://proj/, then the standard SVN layout is
Svn://proj/|+-trunk+-branches+-tags
This is a standard layout, trunk-based development directory, branches for the branch development directory, tags for Tag archive directory (not allowed to modify). But the specifics of how these directories should be used, SVN does not have a clear specification, more or the user's own habits.
There are two common ways to use these development catalogs. I am more from the point of view of software products (such as FreeBSD), because the Internet development model is completely different.
The first method, use trunk as the main development directory.
In general, all of our development is based on trunk development, when a version of/release development (development, testing, documentation, production installer, packaging, etc.) after the end of the code is frozen (artificially defined, can be managed by hooks). This should be based on the currently frozen code base, tag. When the next release/stage development task begins, the development of the trunk continues.
At this point, if you find some bugs in the previous released version (Releasedversion), or some very urgent feature requirements, and the version you are developing (developingversion) does not meet the time requirements, you need to modify it on the previous version. The corresponding branch (branch) should be developed based on the corresponding tag of the release version.
For example, just released 1.0, is developing 2.0, at this point on the basis of 1.0 to make a bug fix.
According to the Order of time

1.0 development Complete, code freezes
Based on the trunk that has been frozen, play tag for release1.0
The directory structure at this time is
svn://proj/
+trunk/(Freeze)
+branches/
+tags/
+tag_release_1.0 (copy from trunk)
2.0 started development, trunk at this time is 2.0 of the development version
Found 1.0 bug, need to modify, based on the 1.0 tag do branch
The directory structure at this time is
svn://proj/
+trunk/(Dev 2.0)
+branches/
+dev_1.0_bugfix (copy from tag/release_1.0)
+tags/
+release_1.0 (copy from trunk)
1.0 bugfix Development in 1.0 Bugfix Branch, 2.0 development in trunk
After the completion of the 1.0 bugfix, Dev_1.0_bugfix based branch do release, etc.
Optionally, merge the Dev_1.0_bugfix branch back into the trunk (when this is done, depending on the situation)
This is a very standard development model, and many companies use this model for development. Trunk is always the main directory for development.

The second method, in each release of the branch to carry out their own development, trunk only to do publishing use.
In this development model, trunk is not responsible for specific development tasks, a version/phase of the development task at the beginning, according to the release version of the new Development Branch, and based on the development of this branch. In the example above, the timing relationship is.

1.0 development, do dev1.0 branch
The directory structure at this time
svn://proj/
+trunk/(not responsible for development tasks)
+branches/
+dev_1.0 (copy from trunk)
+tags/
1.0 Development Complete, merge dev1.0 to Trunk
The directory structure at this time
svn://proj/
+trunk/(merge from Branch dev_1.0)
+branches/
+dev_1.0 (End of development task, freeze)
+tags/
Do 1.0 tags according to the trunk.
The directory structure at this time
svn://proj/
+trunk/(merge from Branch dev_1.0)
+branches/
+dev_1.0 (End of development task, freeze)
+tags/
+tag_release_1.0 (copy from trunk)
1.0 develop, do dev2.0 branches
The directory structure at this time
svn://proj/
+trunk/
+branches/
+dev_1.0 (End of development task, freeze)
+dev_2.0 (for 2.0 development)
+tags/
+tag_release_1.0 (copy from trunk)
1.0 bug, fixed directly on dev1.0 branch

==========================================================================================

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 to master the direction of development, a new module development, this time on the trunk, when the module development completed, need to modify, with branch.
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 completed, 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: Branch
When more than one person cooperates, there may be a situation where John suddenly has an idea that is inconsistent with the original design, may be the addition of functionality or improvements in the log format, and so on, in short, the idea may take a while to complete, and in the process, Some of John's actions may affect Sally's work, and John will have a separate project from the existing state, and not be able to get Sally's corrections to the code already in time, and when John's attempt succeeds, it's difficult to merge with the original. 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.
To create a branch command:

(SVN copy sourceurl/trunkdestinationurl/branchname-m "Creating a private branch ofxxxx/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/trunkfile:///svnroot/mojavescripts/tags/mirrorutils_rel_0_0_1-m " Tagedmirrorutils_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 "Initep"

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 strict measurement of%

================================================================

--A simple contrast

The working mechanism of SVN is like a growing tree in some way:

• A tree with a trunk and many branches
• A branch grows out of a trunk, and a thin branch grows from a relatively coarse trunk.
• A tree can have only a trunk without branches (but this will not last long, and as the tree grows, there will certainly be branches, ^^)
• A tree without a trunk but with many branches looks more like a bundle of sticks on the floor.
• If the trunk is diseased, eventually the branch will be affected, and the whole tree will die.
• If the branch is sick, you can cut it off, and then the other branches will grow out of the Oh!
• If the branch grows too fast, it can be very heavy for the trunk, and eventually the whole tree will collapse.
• When you feel that your tree, trunk, or branch looks beautiful, you can take a picture of it so that you can remember how good it was at that time.

--trunk

Trunks are the primary environment for placing stable code, like a car factory that assembles the finished car parts together.

The following will show you how to use the SVN trunk:

• Unless you have to deal with bugs that are easy and quick to fix, or you have to add irrelevant logic files (such as media files: images, videos, CSS, and so on), you should never do development in the trunk directly.
• Do not make too much of a change to the previous version because of a particular need, how the relevant situation implies the need to create a branch (as described below)
• Do not submit some content that might disrupt the trunk, such as merging from branch
• If at some point you accidentally break the trunk,bring some cake the next day ("with greatresponsibilities come ... huge cakes")

--branches

A branch is a regular copy from a subtree in an SVN repository. Normally it works like a symbolic link on a UNIX system, but once you've modified some files in a svnbranch, and the modified files evolve independently from the copied source files, you can't think of it that way. When a branch is completed, and it is considered stable enough, it must be merged back to its original copy, that is, if it was originally copied from the trunk, it should go back to the trunk, or merge back to its original copy of the parent branch.

The following will show you how to use SVN branches:

• If you need to modify your application, or develop a new feature for it, create a new branch from the trunk and develop it based on this new branch
• Unless you have to create a new child branch from a branch, the new branch must be created from the trunk
• When you create a new branch, you should switch the past immediately. If you didn't, why did you create this branch in the first place?

--tags

On the surface, there is no difference between SVN branches and SVN tags, but conceptually, there are many differences. In fact, a svntags is the "take a picture of this tree" as described above: a trunk or a named snapshot of a branch revision.

The following will show you how to use SVN tags:

• As a developer, never switch to, remove, or submit anything to a svntag: a tag is like some kind of "photo", not a real thing, tags are only readable, not writable.
• In environments where special or special attention is required, such as: production environment (production),? (staging), test environment (testing), etc., only from a fixed (fixed) tag checkout and update, never commit to a tag.
• For the above mentioned environment, you can create the following tags: "production", "staging", "testing" and so on. You can also name the tag according to the software version, the maturity level of the project: "1.0.3", "stable", "latest" and so on.
• When the trunk is stable and can be released externally, it is necessary to recreate the tags accordingly, and then update the relevant environment (production,staging, etc)

--workflow Example

Suppose you have to add a feature to a project, and the project is versioned, you almost need to complete the following steps:

1. Get a new working copy from the trunk of this project using SVN checkout or SVN switch (branch)
2. Use SVN to switch to the new branch
3. Complete the development of new features (of course, do enough testing, including before you start coding)
4. Once this feature is complete and stable (submitted), and is confirmed by your colleagues, switch to trunk
5. Merge your branches into your work copy (trunk) and resolve a series of conflicts
6. Re-examine the merged code
7. If possible, trouble your colleague to review the code you have written and changed (review)
8. Submit a merged work copy to Trunk
9. If some deployments require a special environment (build environment, etc.), update the relevant tag to the revision you just submitted to the trunk
10. Deploy to related environments using SVN update

Reproduced SVN trunk, branch, Tag usage