During the programmer writing the program, each program will have a lot of different versions, which requires a good management code that can take out the required version at needed, and each version has a complete description.
We use Sub Version (SVN) as version management tools. Here, focusing on SVN as multiplayer cooperative use of cross-platform. During the process of managing the same segment code, the management of the version is particularly important, using SVN to make branch, merge, and record all the versions.
basic configuration
When starting a software, the development and writing of the document, first establish SVN warehouses, usernames, and their permissions by the configuration management person, and notify the relevant personnel SVN warehouse address, SVN warehouse person in charge.
The person in charge of the SVN warehouse sets the TSVN: Logminisize of the project to 1 for forced comments. Setting method: In your project folder right -> property, enter the Subversion tab, select TSVN: Logminisize, make sure the check box recursive is selected, then click the Set button to set it to 1, it means the comment submitted The shortest length is one word. Figure:
Figure 2.1
Software configuration
l ignore the file
In [General] of SVN [setting], set the file that you need to ignore to ignore some temporary, useless files, often ignored files with * .opt * .ncb * .su * .plg * .pch * .idb * .pdb * .scc * .obj debug release * .o * .bin * .out * .ilk * .aps debug release * .clw * .bak. Each programmer can modify the ignore file according to your needs, just some ignore files that are often used when using VC and Tornado.
Figure 2.2
The above-mentioned ignoring file refers to the overall ignore file. SVN can also specify files that need to be ignored in a specific directory. Ignore the file support wildcard.
l Merge comparison tool
The tools used to merge can be selected in Merge Tool, which is highly recommended for Araxis Merge. In [Setting] -> [DIFF], "C: / Program Files / Araxis / Araxis Merge V6.5 / Araxis / Araxis Merge v6.5 / Merge.exe"; in [Setting] -> [Merge] option, fill in "C: / Program files / arxis / arxis merge v6.5 / merge.exe "% theirs% MINE% merge;" C: / Program Files / Araxis / Araxis Merge V6.5 / Merge.exe "refers to the path of the merge tool, % Theirs% MINE% MERGED is referred to .. The result of the branch, trunk, and merge will be merged to the backbone.
Figure 2.3
Warehouse directory structure
The person in charge of the SVN warehouse plans a directory structure of the warehouse. The recommended directory structure is shown below.
There are only two first-class catalogs in the warehouse, which are Code and DOC, respectively. Among them, DOC is primarily used to place a secondary document, and CODE is primarily used to place the code of the project, or the later document can be included.
The secondary directory of the warehouse can only be two directorys with Trunk, and the main dry and branches are stored separately. The project file is stored directly under the Trunk directory. In the BRANCH directory, some subdirectories are included in each branch, respectively.
Figure 2.4
When you remove the code from the SVN repository, you must not take the entire warehouse, but you should only take a trunk directory, or take out a branch directory under the BRANCH (such as SVN: // Code / BRANCH / XW_051206).
A project will have multiple people to work together to develop. The basic process is:
l Establish your own branch and develop it in this branch;
l The development members merge branches into the backbone and form a relatively stable version;
l All members have established new branches from the backbone, and developed on this branch (ie back to the first step)
l Cycle reciprocate until the end of the project.
Below I use an example to illustrate the basic processes of cooperation development.
Two developers of XB and LZJ now develop a project online, and the main SVN warehouse address of this project is shown below.
Figure 2.5
The XB and LZJ have two branches in the ONLYTEST project, respectively, and is XB _051115 and LZ_051115, respectively.
Here, the branch name is named [Name Abbreviation _6 ", such as XB_051208_1, XB_051212. After the branch is created, we can see the directory structure of this project as shown below:
Figure 2.6 Branch Directory
After the completion, XB and LZJ were developed locally to the corresponding branch.
When the program arrives at a relatively stable phase, it is necessary to merge the branch to the backbone, and the merged flow is described below.
Continue to use the projects shown in the previous section in this section to explain.
1.2.3.1 XB and LZJ modify the code on your branch, respectively
Now, the Test_Svn.txt on the backbone is an empty document.
After the submission is submitted by XB and LZJ, Test_svn.txt in both branches is shown in the following two figures:
Figure 2.7 Test_svn.txt under the branch of XB_051129
Figure 2.8 Test_svn.txt under the branch of lzj_051129
1.2.3.2 XB combines XB_051129 branches to the main dry
XB first takes the trunk Check Out to the local. Then right-click on the backbone of the directory to select SVN-> Merge, pop up the following window:
Figure 2.9 Merger Dialog
The meaning of this dialog is merged between the difference between the branch version specified by the FROM to TO to the main.
The selection here is XB_051129. The selected method of the version number is to click the show log in from From, hold down the Ctrl key in the log window, click on the version above "Made a Copy", and the top of the version, as shown in Figure 2.11. Then click OK to return to the dialog box above, you will automatically fill out the Revision number in TO.
2.10 Select the version that needs to be merged
Then click on Merge to merge directly, you can also see if there is difference between the Dry Run. Since there is no other person to modify the main trunk, the merger is smooth, the following figure is the result of XB_051115 and the backbone merge. After the combination is completed, the trunk is submitted by XB.
Figure 2.11 After the merger, Test_svn.txt on the backbone
1.2.3.3 LZJ merged the LZJ_051129 branch to the main dry, resolve conflicts
After XB is completed, LZJ will merge his branch to the backbone, the method is the same. However, since the XB has been modified by the main trunk, a conflict dialog box will pop up. Double-click the conflicting file name in the dialog box, you can call out the tool to merge this file. The following figure is the interface we display with the MERGE tool.
Figure 2.12
l First, the first window is compared to the second window, and the result is modified to the second window.
l Then make sure that the cursor is in the second window, click the button shown in the red circle in the figure. This will copy all the contents of the second window to the third hope. Then save, exit.
l Then right-click on the engineering directory and make svn-> resolved. This will delete useless temporary files.
l Submit a modification of the submission and add a detailed note.
Label
Unlike CVS, you do not need to add tags specifically for directory when using SVN because SVN is also managed. We write a note when submitted (such as the date of using 051201 as the beginning), you can find the more important directory version number, equivalent to the label in CVS or VSS.
In addition, each project will have a release document, and you can find a critical version through this file.
You can rename, move, or delete your file or folder, but use SVN to do these operations, otherwise the previous version information will be lost.
Using SVN delete, movement with renaming folders is to right-click on file / folders to perform SVN operations, or use right-click to drag and drop directly in the resource browser (pop-up SVN option).
Before the file deletion, movement and rename, you must ensure that the working directory is the latest version; after these operations, you need to submit.
1.3.3 Return
In the process of writing, it is inevitable that there will be unbelievable places, you may need to fall back to a version, but there may be some files in this process. You don't want to keep, this is involved. A very complex version of the management process, here is recommended for everyone.
1. If you edit the project, under the premise of being submitted, you want to give up these modifications, you can choose Revert directly to update the latest version of the project.
2. If you want to return to a version, you can choose Update to Reversion as shown in the figure, so we can return our version to the version you selected. In this case, the svn does not show anything. Conflicts, and newly established files are also, but in this case you can't edit directly after you retreat, because SVN's version control is still on the latest trunk. We need Update and resolve conflicts.
3. You can choose Revert Changes from this revision as shown in the figure, you can solve conflicts and submit them directly. However, this method is not enough, your newly built files are gone, and the entire project retreats to the previous version.
4. One way I recommend is to directly export a version you need, then override your latest version with your export, so you can not lose your new file, and get the HEAD's SVN control file.
Figure 13
Each project will have many small modules. When a module reaches a stable, you will need to submit it once, so as not to write the next module code, an unrecoverable error occurs.
Every time you submit your needs, you need to check through the PCLINT to ensure that it is a version without an error. When submitting a relatively stable version, you should modify your version number.
1.3.5 version of the document
Version Description file is an XML table, available with Excel editing, which will record the key version information.
The content of the version is as follows. The release version refers to the version number published by the user, which is described in detail later; Revision is the version number of the project folder inside the SVN. A release versions may correspond to multiple Revision:
Release version Revision Details 1, 0, 0, 12 76 Add anti-interference log, you need to reconstruct long-time test program code, have debugged through 77 xxx @ # $% ^ & 78 啥 ... 1,0, 0,13 81 Testing stable version 1, 0, 0, 14 99 FIX Some bug, no test
