During usual work with the project many revisions for each file are created. Each revision appears after the "checkin" operation. In different systems revisions are numbered in different ways, for instance, in CVS numeration looks like "1.34", "1.34.1.3" etc. Actually the numbers of revisions are more important for revision control system itself, but not for a man. Since files in the project are modified irregularly, the actual project revision includes, in general, files of different revisions. To solve this problem a concept called tag was introduced. The same tag can be assigned to many files, this allows to tag the whole project (or its part). Knowing the tag you can get the tagged revision of the project, or perform operations of comparing files more intelligently. Thus, tag is a symbolical connection with the specified revision of a file/files.

Besides the concept of a tag, CVS provides an opportunity of creating branches. A branch is an independent branching from the main tree of revisions, which allows having two or more independent working file revisions. Branches are created mainly for the following purposes: independent development of the current revision with the correction support in the release version, long-term independent work, using of source codes of other developers. All three opportunities are shown in the table. There you can also find a more detailed explanation of the algorithm for each opportunity.

Branch Release	Long, isolated work	Using of codes from 3rd vendors
[root] [1] [2] [3]----)[release] [4] [3.1] [5] ---[3.2] [6] / [7](- [8]---->[releae2] [head]	[root] [1] [2] [3]----)[longwork1] [4] [3.1] [5](----- [3.2] [6] [7]-----[longwork2] [8] [7.1] [9](----- [7.2] [head]	[root] [1]---->[3rdcode] [2](--------[1.1]<3rdcode_update1> [3] | [4] | [5](--------[1.2]<3rdcode_update2> [6] | [7](--------[1.3]<3rdcode_update3> [8] [head]
Permanent development takes place on the main branch. At the time of version release the main branch is tagged, and a branch is created on the base of this tag. When bug fixing in release version takes place, it is performed on the "release" branch. Before issuing of a new release, fixes from the release branch are merged with the basic codes (to prevent repeating of the same errors). Then everything is repeated.	Permanent development takes place on the main branch. When it is necessary to perform long work, a part of developers goes to the "longwork1" branch. There they make modifications, which are merged with the main branch afterwards. The essence of this work is that it is sometimes necessary to modify, for instance, the system kernel. Moreover, the modifications have no effect on functions etc. Modifications are just special internal changes increasing efficiency and so on. The modification can be extensive enough to require work of several developers, or for one developer it may be better to checkin his work step-by-step to the server in order to secure the source codes.	This situation arises when you use ready source codes of other developers. The very first version of theirs is tagged '3rdcode'. Commonly it is necessary to adapt these codes some way: change titles, maybe add new functions etc. This work is performed on the main branch. Meanwhile the imported source codes can also be modified by their "owners". These modifications are added to the branch '3rdcode', and then are merged with the modifications on the main branch.
The project is developed. At the time of the project release the branch 'release1' is created. The project development is continued. At some moment it becomes necessary to fix bugs in the release version. Get the main branch again. Continue the project development. Point 4 can take place several times. A new release is ready. Merge modifications of the branch "release1" with the main branch. Create the branch "release2". ...	The project is developed. At the moment of taking a decision about long work Get the branch 'longwork1'. The branch "longwork1" is modified while others work with the main branch. At the end of work Merge modifications with the branch "longwork1". ...	The code of other developers is used. Right away the branch '3rdcode' is created. Adaptation on the main branch is performed. At the moment you get the new version from other developers '3rdcode_update1'. merge it with the branch '3rdcode'. Adaptation on the main branch is performed. At the moment you get the next new version from other developers create the tag '3rdcode_updató2'. merge it with the branch '3rdcode'. Select modifications performed only between the tags '3rdcode_update1' and '3rdcode_updató2'. Adaptation on the main branch is performed. ...