CVS tag and branch

CVS (Concurrent Version Control System) is a very powerful tool that allows many program developers to develop software at the same time. Most software engineers may have some contact with it. At least the name is a bit harsh. For the basic commands and usage of CVs, there are already a lot of tutorials on the Internet, so I will not be arrogant. This article will introduce two features: tag and branch.

I. Tag 1.1 revision number (revision number) to understand tags, first introduce revision number (revision number ). In CVs, each file version has a unique revision number. The revision number is generally in the following format: '1. 1', '1. 2', '1. 3.2.2 'or even '1. 3.2.2.4.5 '. A revision number always has an even number in decimal format separated by periods. By default, the first revision number of the document is 1.1. The rightmost number of each new revision number is 1 larger than the rightmost number of its last revision number. Some revision numbers are displayed, and newer versions are on the right. + ----- ++ ----- +! 1.1! ----! 1.2! ----! 1.3! ----! 1.4! ----! 1.5! + ----- ++ In fact, Most CVs users do not need to consider the revision number; they only need to know that CVS has automatically added revision numbers like 1.1 and 1.2. 1.2 tag because each file has its own revision number, each time it is submitted, its revision number will be increased. In this case, a problem occurs: for a software release, the revision numbers of the source files may be different. Example: Ci. c 5.21 Co. c 5.9 ident. c 5.3 RCS. c 5.12 rcsbase. h 5.11 rcsdiff. c 5.10 rcsedit. c 5.11 rcsfcmp. c 5.9 rcsgen. c 5.10 rcslex. c 5.11 rcsmap. c 5.2 rcsutil. c 5.10. Therefore, when you want to checkout all the source code of a specific release, if you want to follow the revision number, it is extremely cumbersome and difficult to trace. At this time, we need to use a very dazzling feature provided by CVS: tag ). Tags can be used to mark a group of revision numbers for multiple files. You can imagine that a tag uses a file name as a horizontal axis, A curve is drawn using the version number as the vertical axis (or you can imagine a curve drawn in a matrix composed of file names and version numbers ).

 

In the past, the version with * has been tagged. You can think of a tag as a curve that passes through all marked files. When you grab the line, you will get all the versions marked with labels. You can also look at this in another way: Straighten the curves of all versions marked by the same tag, and then directly look at the past.

 

 

1.3 usage of the tag command
The following example shows how to add a label to a file. The command must be issued in the module's working directory. That is to say, you should issue this command in the directory where the backend. c file is located. $ Cvs tag rel-0-4 backend. c T backend. c $ cvs status-v backend. c ======================================================== ==================================== File: backend. c Status: Up-to-date Version: 1.4 Tue Dec 1 14:39:01 1992 RCS Version: 1.4/u/cvsroot/yoyodyne/tc/backend. c, v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) Existing Tags: rel-0-4 (revision: 1.4) seldom adds Tags to a single isolated file. A more common usage is to add tags to all files in a module after each milestone task in the product development cycle is completed, such as when the release is complete. $ Cvs tag rel-1-0. cvs tag: Tagging. T Makefile T backend. c T driver. c T frontend. c T parser. c (when a directory is used as a cvs parameter, this command not only performs operations on all files in the directory, it also recursively performs operations on the files in all subdirectories in the directory .)
If you want to check out a version of a module, you can use the checkout-R command. Use the '-R' flag in the checkout command to check a version of a module. The following command can easily retrieve all the source files of the 'tc '1.0 Release: $ CVS checkout-r rel-1-0 TC 1.4 when to use the tag Tag feature is like creating a snapshot at a certain point in time for your project. After a tag is added, no matter whether your source file is modified, you only need to find that your modification has an error, or if someone claims that there is a bug in a specific version, however, if you cannot find the bug in the current working copy, you can roll back it based on the tag, or Checkout the snapshot. Tag brings convenience to developers. Therefore, tags should be used in any important development phase. In general, you should consider a snapshot (TAG) for your project resume in the following situations ): completed an important feature. Before each milestone removes an existing feature, before the test starts, you can create a new branch before making major changes to the source file (branch will be discussed in detail below) of course, these are general suggestions. In fact, I feel that when you think the modifications may have side effects, you should tag them. 2 tag and branch

In SVN, branch/tag is often confused in a function option.

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 tags and when to use branch, it is entirely subjective to choose based on specifications and needs, rather than mandatory (such as CVS ).

Generally,
Tag is used to build 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, if 3.0 is developed, a tag, tag_release_3_0 will be created at this time, and then the release will be implemented based on the tag, such as the installer. Trunk enters the development of 3.1, but 3.0 discovers a bug. Therefore, you need to create a branch based on tag_release_3_0, branch_bugfix_3_0, and perform bugfix based on this branch. When the bugfix ends, create a tag, then, determine whether branch_bugfix_3_0 is incorporated into the trunk as needed.

Note that SVN is a global version. In fact, this is a tag, So we 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 it is more readable. After all, it is much easier to remember tag_release_1_0 than to remember a large version number.

 

Branches: Branch

When many people work together, John suddenly has an idea that is not the same as the original design. It may be the addition of functions or the improvement of the log format. To sum up, this idea may take some time to complete. In this process, some operations of John may affect Sally's work. If John has a separate project from the existing state, however, it is not possible for Sally to correct the existing code in a timely manner. If Sally makes an independent attempt, it is also difficult for John to merge with the original one. In this case, the best practice is to use branches. John builds his branch and tests it in it. If necessary, he gets updates from Sally's trunk or collects his stage results into trunk.

(Svn copy SourceURL/trunk DestinationURL/branchName-m "Creating a private branch of xxxx/trunk .")

Trunk: trunk

The backbone is generally the main area of development,

Tag:

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.

(Svn cp file: // svnroot/mojavescripts/trunk file: // svnroot/mojavescripts/tags/mirrorutils_rel_0_0_1

-M "taged mirrorutils_rel_0_0_1 ")

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 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.

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, so that the Code developed in Phase II will not affect the code of phase I, the 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, after modifying the bug, compile the latest code on branches and release it to the production environment. Tags is used to combine the code of the bug modified on branches to trunk and create a version ID, after the bug code modified on branches is merged to the trunk, it is merged from the tags version to the latest version of branches to the trunk, so as to ensure that the bug code modified earlier will not be merged.