CVS version management

The software industry has a "28" or "37" principle for software use. I don't know whether it was summarized by the boss, but it is very accurate. We have been using CVS to manage code, but I want to say that I have been using the most basic part of CVS. CVS Co, cvs ci, CVS up, and CVS add are the most basic functions. I have never carefully studied cvs. Sorry!

I have been involved in the project release for some time, during which I experienced the baptism of market blood and fire .... This is the case for application software. You will certainly encounter different needs of different users, and you need to customize the development for them. Well, when users in province a have special requirements, we use CVS to create a new project for them. Similarly, when users in province B have special requirements, we still adopt the same approach. At the beginning, we didn't think it was so bad that we set up different projects for different users, which was clear and easy to maintain. Like the plot in the day after tomorrow, you always have to pay a painful price for your incorrect practices. We soon discovered the fatal injury of our practice. When we need to modify a bug, upgrade the program, and add common functions, we need to manually synchronize many versions. God, a lot of repetitive work! I heard the complaint from the cute girl next to me clearly: It's really troublesome, so many versions need to be synchronized.

Sometimes, I feel very lucky. When I was troubled by a problem, when I was preparing to consult guru in a frequent forum, I found that everyone was discussing the problem. This is almost the same time. One night I chatted with a previous colleague about version management. The colleague is currently working in a foreign company. It is said that their version management is very standard and there are very professional specialists to do this. He told me that the branch Function of CVS should be used to solve this problem. Although I was confused at the time, I didn't quite understand that he was not doing version management, but what matters was this idea. I am an expert, and I will immediately seek out the book "CVS-Open Source Software Development Technology" from a colleague. I carefully studied the functions of the Branch. Hey, that's what I want. Haha, I jumped in the house for a while. Well, programmers are always so happy and miserable!

I adjusted my light cavalry speaker to a loud voice and listened to "crazy". I like writing articles like this. Okay. Let's see what the CVS branch is.

A major development process of a project is called the Development Main Line. When a special event occurs, for example, if a user has special requirements, a cross is separated from the main development line to meet the special requirements of the user, this cross has its own development direction. This is a branch, like a new branch that grows when a big tree blooms in spring.

--------- Branch
/
/
/
------ ● ---------------------------- Main development line

The above points represent the latest version of the Development Main Line. At this time, you can create branches from the Development Main Line for custom development. Next, the Development Main Line and branch can have various development directions. In addition, if possible, the branch code can be re-merged into the main development line. The code of the Development Main Line can also be updated to the branch code.

Suppose the proj directory under our home directory is our project. The following describes how to create a branch:

1. First create a tag on the development main line, that is, the point in. This is to enable the trunk to return to the status when the branch is created. Execute the CVS tag Root-of-Version_2.5.0.0 at the top level of your project directory.

2. Create a branch: CVs tag-B ln_version_branch (the-B option is to create a branch ).

3. Next, you can directly execute CVS update-r ln_version_branch under the top level of the project directory to go to the branch for work. You can also run the CVS co-r ln_version_branch-D ln_proj proj command to generate a local copy of the branch in the new checkout. The-D option is the name of the local directory to be created. We recommend that you use the second method, because the command can be used to switch back and forth between the main line and the branch in a local copy, which may lead to confusion and you may forget to do so.

4. Branch development and main line development can be separated. If necessary, you can merge the code on the branch to the main development line. Of course, some conflicts may need to be resolved during the merge process. CVS Update-J ln_version_branch: Use this command to merge the branch code to the main line. Of course, the example here is the branch generated for the special needs of users. Generally, the Branch will not be merged into the main development line. However, for the branches generated by bug modification, it is necessary to merge the branches into the main line. One thing to emphasize here is that programmers on the main development line need to communicate with each other when merging the code of the branch. After the main-line programmer successfully merges the branch code, a CVS tag should be set up on the main-line code to mark the merger. After the merge, the programmer who develops the branch code, we also need to create a vertex to mark this merge, for example, CVS tag ln_version_1. The advantage of this is that when the code is merged next time, the programmer on the Development Main Line can run the command CVS Update-J ln_version_1-J ln_version_branch. Here ln_version_branch indicates the branch end, therefore, this command is not used to re-merge the entire branch code, but to merge the code modified since the merge point ln_version_1, which can prevent conflicts caused by re-merge of the entire branch.

5. For the branches generated for special user requirements, we may need to update the code on the main development line to the branch. CVS Update-J head. Here the head represents the ending point of the trunk, that is, the command merges the code modified on all the main lines at the beginning of the creation of the branch. The branch developers need to communicate with the main line developers. You also need to set up a vertex to mark the merge. If the main line needs to merge the branch code, you can perform a new merge Based on the vertex instead of merging the entire branch. The main line developers also need to set points to mark the merge, for example, CVS Tage merged-ln_version_1, so that the next branch can be CVS Update-J merged-ln_version_1-J head when merging the main line code, this prevents the branches from merging the code on the main line repeatedly, but only merging the latest modifications.

As we can see above, one of the main rules is that when merging code, you must pay attention to communication and set the merging points reasonably. In addition, the name of the merge point should also be defined as follows. It is also best for one person to merge jobs online. If the merge point is set improperly, the benefits of the branch may be compromised. In addition, if the management is poor, the entire project may be messy and produce the pasta branch ^_^.

I have briefly described some of the Branch functions in CVS. I have limited expression capabilities and may not be very clear about them. If you are interested, you can refer to the relevant information for details. But what matters is idea, right? I still have a rock here. I think it is not until today that I have pulled out the CVS long sword, but I just pulled it out. To make it stand alone, I still need to work hard ....

 

 

 

Select fromZhanghx6986Blog