SVN's standard directory structure: trunk, branches, tags
<!-- .entry-meta -->
In the repositories of some well-known open source projects, we usually see three directories such as trunk, branches, and tags. Due to the inherent characteristics of SVN, directories have no special meaning in SVN, but these three directories exist in most open source projects because these three directories reflect the usual patterns of software development.
trunk is the main branch, where day-to-day development takes place.
branches are branches. Some staged release versions, which can continue to be developed and maintained, are placed in the branches directory. Another example is a version customized for different users, which can also be developed in a branch.
The tags directory is generally read-only, where staged releases are stored and archived only as a milestone version.
For example, a project has two files, main.cpp and common.h. Assuming that the latest 3.0 version is currently under development, and the 1.0/2.0 version is also being maintained, the project tree will be similar to the following:
project
|
+-- trunk
+ |
+ +----- main.cpp (latest file for version 3.0)
+ +----- common.h
+
+-- branches
+ |
+ +-- r1.0
+ + |
+ + +---- main.cpp (latest file for 1.x version)
+ + +---- common.h
+ +
+ +-- r2.0
+ |
+ +---- main. cpp (latest file for version 2.x)
+ +---- common.h
+
+-- tags (this directory is read only)
|
+-- r1.0
+ |
+ +---- main.cpp (1.0 version release file)
+ +---- common.h
+
+-- r1.1
+ |
+ +---- main.cpp (version 1.1 release file)
+ +---- common.h
+
+ -- r1.2
+ |
+ +---- main.cpp (release file for version 1.2)
+ +---- common.h
+
+-- r1.3
+ |
+ +---- main.cpp (release file for version 1.3)
+ +---- common.h
+
+-- r2.0
+ |
+ +---- main.cpp (release file for version 2.0)
+ +---- common.h
+
+-- r2.1
|
+---- main.cpp (release file for version 2.1)
+---- common.h
To use such a folder structure, when building a project repository, you can first build a project folder, and create three empty subdirectories of trunk, branches, tags in it, and then put the project The folder is imported into the repository along with these three subdirectories.
In this way, the development starts in the trunk. When a branch or tag needs to be established, the copy operation of SVN is used for it.
The tags directory needs to be read-only. You can use the authz file in SVN to control the access permission of this directory to read-only.
This section mainly explains the usage of tag branch trunk in SVN. In SVN, Branch/tag is a function option, which often causes confusion in use. Here is a brief introduction to you, and you are welcome to learn the usage of tag branch trunk in SVN with me.
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 tag and when to use branch, it is entirely up to people to choose subjectively according to specifications and needs, rather than mandatory (such as cvs). Under normal circumstances, tag is used to make a milestone, whether it is a release or not, it is an available version. Here, it should be read-only. More of a display, giving a readable markup. Branch is used for parallel development. The parallel here refers to the comparison with trunk. For example, when the development of 3.0 is completed, a tag, tag_release_3_0, should be made at this time, and then a release will be made based on this tag, such as an installer. Trunk entered the development of 3.1, but 3.0 found a bug, then you need to make a branch based on tag_release_3_0, branch_bugfix_3_0, and perform bugfix based on this branch, wait until the end of the bugfix, make a tag, tag_release_3_0_1, and then decide whether branch_bugfix_3_0 is merged into trunk as needed. Another thing to note about svn is that it is a global version number. In fact, this is a tag mark, so we can 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 this is more readable, after all, remembering tag_release_1_0 is much easier than remembering a large version number.
branches:
The usage of tag branch trunk in branch SVN, first look at the introduction of branches. When multiple people cooperate, there may be situations like this: John suddenly has an idea, which is not consistent with the original design, it may be the addition of functions or the improvement of the log format, etc. All in all, this idea may take a while to complete. , and during this process, some of John's operations may affect Sally's work. If John separates a project from the existing state, he cannot get Sally's corrections to the existing code in time, and if it is independent, John's attempt When successful, there are also difficulties in merging with the original. The best practice at this point is to use branches. John builds his own branch, then experiment in it, getting updates from Sally's trunk if necessary, or pooling his stage results into the trunk.
(svncopySourceURL/trunkDestinationURL/branchName-m"Creatingaprivatebranchofxxxx/trunk.")
trunk: trunk
trunk, generally speaking, is the main place for 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 in this stage, then you can The code needs to be tagged.
(svncpfile:///svnroot/mojavescripts/trunkfile:///svnroot/mojavescripts/tags/mirrorutils_rel_0_0_1-m"tagedmirrorutils_rel_0_0_1") said otherwise, it doesn't matter who is right or wrong.
trunk: Indicates the directory where the version is stored during development, that is, the code in the development phase is submitted to this directory.
branches: indicates the directory where the released version is stored, that is, the stable version released when the project goes online is stored in this directory.
tags: Indicates the directory where tags are stored.
It is necessary to explain the reasons for the three categories below. If the project is divided into Phase I, Phase II, Phase III, etc., then the stable version when Phase I is launched should copy the code to branches when Phase I is completed. The code developed in the first phase has no effect on the code of the first phase, for example, the newly added modules will not be deployed to the production environment. The stable version on branches is the code released to the production environment. If a user finds a bug in the process of using it, he only needs to modify the bug on the branches, and after modifying the bug, compile the latest code on the branches and release it to the production environment. That's it. The role of tags is to create a version identifier when merging the bug code modified on the branches into the trunk. Later, when the bug code modified on the branches is merged into the trunk, it will be merged from the version of the tags to the latest version of the branches into the trunk. In order to ensure that the bug code modified in the early stage will not be merged again.
-------------------------------------------------- -----------------------------------------
When introducing the usage of tag branch trunk in SVN, I have always used svn as a cvs, and I have never read the documentation carefully. Until I used it today, I went to look at the svnbook documentation. I am ashamed.
Requirement 1:
There is a customer who wants to customize the product, but we do not want to modify the original one. Code for trunk in svn.
Method:
Create a new branch with svn, and use this branch as a new starting point to develop
svncopysvn://server/trunksvn://server/branches/ep-m "initep"
Tip:
If your svn does not have it before The directory of branches is only trunk. You can
create a new directory with svnmkdirbranches
Requirement 2: The
product development has been basically completed and has passed very strict tests. At this time, we want to release it to customers and release our 1.0 version
svncopysvn://server/trunksvn://server/tags/release-1.0-m "1.0released" Hey, what's the difference between this and branches, it seems that there is no difference at all?
Yes, branches and tags are the same, they are both directories, but we will not make changes to this release-1.0 tag, and no longer submit, if submitted, then it is branches
Requirement 3:
One day, a fatal bug is suddenly found in the core under trunk, so all branches must be the same, what should I do?
svn-r148:149mergesvn://server/trunkbranches/ep where 148 and 149 are the version numbers of the two revisions. The usage of tag branch trunk in SVN has been introduced.
This article mainly explains the composition of trunks, branches and tags of SVN, mainly including the explanation of its concepts and the comparison of usage. I believe you will gain a lot after reading this article. I hope this article can teach you more things.
In this article, I will explain in detail how I applied SVNtrunk (trunk), branches (branch) and tags (marker). This approach is also called "branchalways" and the two are very close. Maybe what I have presented is not the best method, but it will give newbies some explanations about what trunks, branches and tags are and how to apply them.
Of course, if there are some points in this article that need to be clarified/confirmed, or if there are some wrong points of view, please comment and express your own opinions freely.
- A simple comparison
of how SVN works is somewhat like a growing tree:
a tree with a trunk and many branches
grows branches from the trunk, and thin branches grow from a relatively thick trunk A
tree can be made with only a trunk and no branches (but this situation will not last long, as the tree grows, there will definitely be branches, ^^)
A tree without a trunk but with many branches looks more like a floor If a bundle of branches
is diseased, eventually the branch will also be affected, and the whole tree will die.
If a branch is diseased, you can cut it off, and the other branches will grow!
If the branch grows too fast, it can be very heavy on the trunk and eventually the whole tree will collapse.
When you feel your tree, trunk or branch looks beautiful, you can take a photo Just remember how awesome it was back then.
- Trunka
SVN makes up Trunka, the main environment for placing stable code, like a car factory, responsible for assembling finished car parts together.
The following will tell you how to use SVNtrunk:
Unless you have to deal with some bugs that are easy and quick to fix, or you have to add some extra logical files (such as media files: images, videos, CSS, etc.), never use trunk Go straight to development
Don't make drastic changes to previous versions for special needs, whatever the situation means, you need to build a branch (as described below)
Don't commit something that might break the trunk, such as merging from a branch
If you accidentally break the trunk at some point, bringsomecakethenextday("withgreatresponsibilitiescome...hugecakes")
- Branches
SVN makes up branches, a branch is a normal copy made from a subtree in an SVN repository. Usually it works like symlinks on UNIX systems, but once you have modified some files in an SVNbranch, and the modified files are developed independently from the copied source files, this is not the case. When a branch is completed and considered stable enough, it must be merged back to where it was originally copied, that is: if it was copied from the trunk, it should go back to the trunk, or merge back into its original The parent branch of the copy.
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 then develop based on this new branch
unless it is necessary to start from Create a new subbranch within a branch, otherwise the new branch must be created from the trunk.
When you create a new branch, you should switch to it immediately. If you didn't, why did you create this branch in the first place?
——Tags
SVN forms Tags. On the surface, SVNbranches and SVNtags are no different, but conceptually, they have many differences. In fact, an SVNtag is the "take a picture of the tree" described above: a named snapshot of a trunk or a branch revision.
The following will show you how to use SVNtags:
As a developer, never switch to, take out, or commit anything to an SVNtag: a tag is like some kind of "photo", not a real thing, tags are only readable, not writable.
In special or need special attention environment, such as: production environment (production), ? (staging), test environment (testing), etc., only checkout and update from a fixed (fixed) tag, never commit to a tag.
For the environment mentioned above, the following tags can be created: "production", "staging", "testing", etc. You can also name tags according to the software version, the maturity of the project: "1.0.3", "stable", "latest", etc.
When the trunk is stable and ready to be released, recreate the tags accordingly, and then update the relevant environment (production, staging, etc)
- the workflow example
assumes that you have to add a feature to a project, and this The project is under version control, and you need to complete the following steps:
use SVNcheckout or SVNswitch to obtain a new working copy (branch) from the trunk of this project.
Use SVN to switch to the new branch
to complete the development of new features (of course, to Do enough testing, including before starting coding)
Once the feature is complete and stable (committed), and confirmed by your colleagues, switch to trunk
merge your branch into your working copy (trunk), and resolve a series of Recheck
the merged code
If possible, ask your colleagues to do a review of the code you wrote and changed.
Submit the merged work copy to trunk
If some deployments require a special environment (build environment, etc.), please update the relevant tags to the revision you just submitted to trunk, deploy to the relevant environment using SVNupdate
Tags:svn, translate. The concepts, functions and usage of trunks, branches and tags in the composition of SVN are introduced. Stay tuned for other coverage in this section.