The software industry has a "28" or "37" principle for software. I don't know if it is the boss, but it is really accurate. We have been managing the code with CVS, but I want to say that I have always used the most basic part of CVS. CVS CO, CVS CI, CVS UP, CVS ADD, are the most basic functions, I have never been carefully studying CVS, embarrassing!
I participated in the project Release for a while, during which this time I experienced the baptism of the market and fire ... This is the case, this is the case, you will definitely touch the different needs of different users, you need to customize it for its customization. Ok, when there is a special demand for users with a province, we use CVS to build a new project. Similarly, when there is a special demand for B, we use the same way. We didn't think this is not good at the beginning. It is very clear and convenient to maintain different project for different users. Just like the plot in the "Sky", you always have to pay a painful price for you incorrect practice. We quickly discovered the fatal injuries of our approach. When we need to modify a bug, or when we upgrade the program, we need to manually synchronize a lot of versions. GOD, a lot of repetitive labor! I clearly hear the complaints of the lovely girls in my neighborhood: I am really trouble, so many versions to synchronize.
Sometimes, I feel very lucky ^ _ ^. When there is a problem that is plagued me, I will prepare for the previous forum to ask Guru, I found out that everyone is on the world. This time, I have talked some questions about version management one night and a previous colleague. That colleague is now working in a foreign company, allegedly in which their version management is very standardized, and very professional specialist to do this. He told me that you should use CVS branch function to solve this problem. Although I was in the mist, I didn't quite understand, but he didn't make a version management, but it is important that this IDEA. I am a person who listens to people, immediately coming from a colleague to "CVS-open source software development technology" book. Carefully study the feature of the branch. Hey, this is what I want, haha, jumping in the house, a small swan. Well, the programmer is always like this!
Turning my light cavalry speaker very loudly, listening to "I am infatuated". I like to write this article ^ _ ^. Ok, let's take a look at what is CVS branch.
We call a major development process of a project as a development main line. When a special event occurs, for example, there is a special need to have a special demand, so it is separated from this development main line to meet the special needs of users, then this fork has its own development direction, this is Branch, like a big tree in the spring blossoms, the new branches grow up.
--------- Branch / / / ------ ● ---------------------------- Development Main line
Above this point, represent the latest version of the development of the main line, then this time can be customized from the development of the main line to create a branch. Next, develop mainlines and branches can have various development directions. Moreover, if possible, the branch's code can be re-incorporated into the development main line. The code for developing the main line can also be updated into the branch code.
Assuming that the Proj directory under our home directory is our project. Let's take a look at it, how to build a branch:
1. First create a label on the development main line, that is, the point in the figure above. This is to make the need for the status when the trunk is re-returned to the state. Under the Top Level of your project directory, perform CVS Tag Root-of-Version_2.5.0.0.2, create a branch: CVS Tag -b ln_version_branch (-b option is created).
3, next, you can perform CVS Update -R LN_Version_branch to transfer to the branch under the top level of the project. You can also command a local copy of the new Checkout by CVS Co -r Ln_Version_branch -d ln_proj proj command. The -d option is to create a local directory name. It is recommended to use the second usage because it is easy to confuse in the main line and branch conversion under a local copy, you may also forget to do this.
4. This development and main line development can be separated. If needed, you can merge the code on the branch to the development main line, of course, some conflicts may be required during the merge. CVS Update -j ln_version_branch, combines branch code to the main line through such a command. Of course, the examples of us here are branches arising from special needs of users, generally not merged into the main line. However, for branches arising from bug modifications, there is a need to merge branches to the main line. One point here is to emphasize that when developing the programmer of the main line, it needs to communicate with each other. After the development of the main line programmer successfully merges the branch code, set up a point (CVS TAG) on the main line code to mark this merge; the programmer developed on the branch code, after the merger, it is also necessary to establish a point to mark this Sub-merge, for example, CVS TAG LN_VERSION_1. The advantage of this is the next time the code merges, the programmer on the development main line can pass the command cvs update -j ln_version_1 -j ln_version_branch, where LN_Version_branch represents the end of the branch, so the command is not re-incorporating the entire branch code. Instead of consolidating the code from the merge point LN_Version_1 to the current modified, it can prevent the conflict caused by reconciling throughout the branch.
5. For the branches of our special demand for users here, it may be more necessary to update the code on the main line to the branch. CVS Update -j Head, here Head represents the end of the trunk, that is, this command merges the main line to create the code to the current, all the modified code. Here is also a branch developer and main line developer communication. A point in the branch also needs to mark this merge, so if the main line needs to merge branch code, you can make new merges based on this point, not the consolidation of the entire branch. The main line developer also needs to set a point to mark this merge, for example, CVS TAGE MERGED-LN_VERSION_1, such a next branch, can CVS Update -j merge-ln_version_1 -j mead, which prevents the branch repeated merger The code is just the latest changes.
Above we can see that a major rule is that when the code is merged, you must pay attention to communication, reasonable sets of merge points. Moreover, the name of the merge point should also look at the word ". The mergers on each line are also best made by one person. If the consolidation point is set properly, then the benefits of branches may be discounted. And if management is not good, the entire project may be very chaotic, producing the branch of the Italian noodles ^ _ ^.
