| |
Today, the company's SVN server is configured to do a bit, depending on the corporate sector, the division of the different access to the directory, and to configure a different directory appropriate permissions, and be put to finish this job, but in fact my own job dissatisfaction and regret, because the current configuration of the company's SVN server management practices do not comply with the code, no branches, no label, do things I always want things to the extreme, at least the top-level design should be reasonable, convenient later people, but to realize my ideas as the company's smaller Rolls-Royce I am not qualified to push, forced obscenity in this article to it, and how to use SVN fantasy standardized tools to make the source code management.
1. SVN Overview
With the increasing size of the project, before modifying the code by mail delivery way become stretched, and has seriously affected the efficiency of our work, since we will be using SVN to manage the development of the project.
SVN stands for Subversion, a version control system that can give the team time to develop the project brings many benefits: It gives teams a project-level Undo function, nothing is finalized, the error can easily be back roll. Namely, whether the team member edits when, can be undone.
It allows multiple programmers can be ordered at the same time for the same program to write code. The team will no longer be covered because someone edits other team members lost work done.
Version control system records the changes all the time. If you encounter some modified code, to find who will be very convenient when writing, you can also understand why you want to write the log.
Version control system allows you to carry out development while maintaining the main line of multiple releases. With version control system, you need to make before the release team to stop working to freeze the code.
Version control system is a project-level time machine that lets you enter a date then you can see the way the project.
Although SVN can help our team to collaborate more effectively, but if used improperly, it not only did not give us any of the convenience, but will reduce the efficiency of our work, therefore the preparation of this specification, the purpose is to facilitate the work.
2. The directory specification
SVN directory structure full projects generally have three folders: 1.trunk, 2.branches, 3.tags, in a standardized project these directories are essential balance between efficiency and safety codes. Let me explain their role.
2.1Trunk
Any time Trunk contains are the latest development code. Here's the code will work until your next major release. As far as I can see, only the trunk almost always people use to store their code. Issued a release after proceed to the next version of the development thereon. This is not good, either for you or your product. Trunk should only be used to develop will be your next major version of the code. Do not add to the trunk version and release names. Only need to ensure that trunk at all times in the "development model." Examples: https://svn.example.com/svnroot/project/trunk
2.2 Branches
There are several different types of branches. Here I will tell you some common types. In the branches of the directory, you can create a path for the more specific objectives, such as the upcoming release. As my article "article on releasing software from Subversion" as discussed in, brahches path contains a copy of the trunk at different stages of development.
2.2.1 Release Branches
We've seen the RB-x.x release branches. When the trunk reaches a stage ready for release (or if you want to freeze the new features added), you should create a release branches. Release branches is just a copy of your current trunk. The branches can be individually checked out you can also start and branches based on this version of the project. You can also use this branch during testing repair Bug. This approach ensures trunk continue to develop, and will not be released to a specific version of interference. So when you are ready to release a new version, this will not affect your trunk to add new features.
2.2.2 Bug fix branches
Branches can also be used to handle serious Bug trunk or release branches in discovery. The Bug is very complex, you can not commit the time to repair them. Therefore, in order to focus on correcting this error, you should create a new branch for this problem. This will not affect the continued release branches and trunk, and you will not because of the discovery of new Bug and interference testing this Bug fixes. Bug fixes branch naming usually follow the following ways: Use your defect management system assigned to this Bug's ID. Usually this is a number. Such as: Bug-3391. Of course, you can also access your Bug branch, like other branches of the same.
2.2.3 Experimental branches
Sometimes you want to introduce a new technology projects. That's fine, but you certainly do not want to bet your entire project. Imagine that you want your Web program from PHP4 to PHP5. How much time you spend? During this period, stop using your trunk? Until you have all the PHP5 conversion done! This is experimental, the other end may PHP5 like a rainbow, like too far away from your program, you should give him create a branch. You can make changes in the branch and, if that fails, you still have PHP4 code in the current branch. If it fails, the experimental branch can be discarded. If successful, you can easily be merged into the trunk and go on with your new technology. Experimental branches follow the naming principle surface: its name prefixed with "TRY-".
2.3 Tags
Tag as the branch as a backup of your code. But Tag is not used to develop, they are only used to mark the status of your code.
1.3.1 Release tags Release Tags
Markup you release point. Release Tag is always the publisher a copy of the branch. Release Tag naming: "REL-" prefix plus a version number.
1.3.2 Bug fix PRE and POST tags
When you create a Bug fix branch, you want to mark code status before and after BugFix. So you can easily reference your changes, merged into trunk or Release branches. Naming rules: "PRE-" plus Bug ID; "POST-" add Bug ID.
3. SVN Use
To update, and then submit
Principles SVN update is to be updated at any time submit. When we completed a small function, and then be able to compile their own tests, carefully committed. If during the modification of others changed the svn correspondence files, then commit it might fail. If you change others and themselves is the same file, it will automatically update when combined, if you modify the same line, it will merge conflicts, this situation needs to contact with the developer before the two people consultation conflict after conflict resolution, and together they need to test to ensure that after the settlement of the conflict, does not affect other functions.
Note that when you update the list of update files, if submission process produces updates, you also need to be recompiled and complete their necessary tests, and then submit. This will help others understand what files are changed, but also to avoid errors SVN merge code is wrong.
Multi Submit
Intermittent each submission as short as possible, with a few hours of development work is appropriate. For example, when you change the UI interface, you can modify or complete each design a UI interface, once submitted. In the development of functional modules, you can complete each small detail function tests, once submitted, modify bug when a bug out of each modification and make sure to modify this bug, will be submitted once. We advocate more committed, more will also be able to add on insurance code.
Do not submit through the compiled code
Before submitting the code, first make sure that they can be compiled locally. If you use a third-party library in your code, taking into account that some members of the project team members may not have to install the appropriate third-party libraries. Project Manager in the preparation of the project work area, the need to take into account such a situation, ensure that the development team members can be compiled in a unified environment after checked out code.
Each submission must be written in clear labeling
Use SVN in a project group, if you submit an empty label or inaccurate labels will allow the project team other members feel helpless, unable to progress very clear grasp of the work of the project manager can not grasp this submission clearly outline information. After discovering the error can not be accurately positioned to cause the wrong file. Therefore, when you submit work to fill out the clear labels, information file can be submitted a summary description, let the other members of the project team after seeing the label without detailed look at the code will be able to understand your changes.
Be careful not to commit the local auto-generated file submission
For example eclipse in .classpath files, Windows generates thumbnails Thumbs.db, temporary files generated by the project compiled .obj, .class, and so on. If you do not configure this aspect of the project to prohibit forced to submit such a file, please consciously do not submit such a document. After submitting such a document, others may be updated after the local environmental conflicts affecting everyone's work. Do not submit themselves do not understand the code
After submitting the code into SVN, your code will be shared by project members. If you submit you do not understand the code, you can not read, can not read someone else, if there is a problem in the future will be the project quality risks. Therefore, before the introduction of any third party code, the code is to ensure that you have a very clear understanding.
Lock with caution
In the project to be used with caution in locking function after you lock a file that others can not continue to modify
Submit the file, although you can reduce the incidence of conflict, but may affect the work of other team personnel. Usually only when editing a file that can not be combined (such as image files, flash files, etc.), use only the appropriate lock operation.
4. General operation
4.1 file checked
After you install TortoiseSVN, SVN will follow Windows Explorer integrates perfectly. Right-click, we can choose "SVN checked out" option, enter the file library to check out the code of the URL, we can check out the file repository URL address under the menu bar. The default is checked out the latest version of the code, if needed, we can view the log, according to the log to find the desired version, and then specify the appropriate version in the "Version" option can be detected in the relevant code 1. After that, the backbone of the development of the same project, we are under the detection code file directory operations, rather than each time re-submit or update is detected again.
4.2 files are added
File we created in the local (including catalog) is not affected by SVN control, in order for it to accept the SVN control must be added to the file library. For files other team members need, such as code files, some modules .a file (some need, the module code is not disclosed), we must allow them to accept SVN control, and keep the latest version.
4.3 File Deletion
When we need to delete unwanted files (including directories), you can not use the Windows Explorer tool, you must use SVN's own function to delete files. After this the file is deleted, all of its revision of history remains in the SVN server, later you can still get the files modification history.
4.4 file renamed
When we need to file (including directory) were renamed, you can not use the Windows Explorer tool, you must rename the file using SVN own function. After this the file is renamed, rename all of its history before the modification remains in the SVN server, maintaining a continuous modification information.
4.5 Update
Other team members to submit the changes to SVN is not automatically updated to your local copy, we need to get the other members of the modifications made to the project file by file update operations. SVN update file file file library operations will merge with the local file, so as to achieve the object while leaving the other members of the local changes and modifications. If you can not automatically merge conflicts occur, you need to use a file comparison tool to manually merge in order to submit the file to resolve the conflict after completion of the merger. Detailed methods to resolve the conflict, see Chapter 3 - conflict resolution. When the development team, the update is a very important job, you can keep the content of the work between team members agreed, so pay attention to regularly update their working copy, to ensure that they can get the latest content. 4.6 submit changes
Our files (including directories) did everything changes, including add, delete, modify the file must be submitted to the SVN server file repository to come into force, after the other members of the team can get the changes you made.
It is important to submit an action required:
1) must ensure that the code before submitting the revised code can be compiled by compiled code can not be submitted not passed. comparison before the amendment and the revised code, the debugging information, or other irrelevant information removed, again to ensure that the code is submitted
Correct and submit the documents to be submitted.
2) Do not wait to modify a lot of code to submit, but upon completion of the relevant small features should be submitted once. Such later discovered to ask
It is easy to withdraw when the problem code in question - because the withdrawal only against submission, so in one submission was involved too much functionality is not recommended.
3) must be completed when submitting log message stating that this submission what additional features or fixes what bug. This information will help
On their own and other team members to understand the history of the entire project. When a problem occurs also conveniently positioned to the corresponding version of the code, so the log information must be detailed enough.
4) transactional commit. That submission either succeed or fail - that the author will be automatically rolled back when an error occurs, the real
Did not submit anything on the occasion. When an error occurs, resolve the errors, we can submit the entire contents of the last commit again.
Appendix: test automation team SVN use guidelines
Construction of 1.Project
Project on the SVN server's directory structure
Project files on SVN:
1. Trunk must ensure that the code is on the latest! Trunk on a regular basis to update the code, each group according to their actual
Hold their own case
2. Tag may be required for your project by playing tag, each released version to be played Tag, mainly to facilitate it necessary
Tag directly from the state to return to the previous, in order to analyze, test; Tag must contain the appropriate release documents and then publish or compile the source code, you must have the relevant documents indicate project background, publishing and so on.
3. Branch folders can be used as a backup, you can use personal folders named; moreover, Branch branch is mainly used
Brief exploratory development or use of the final version of the software must be updated to merge the Trunk trunk. 4. Recommendations on the same project team development environment: the same project team members consistent with the best development environment, software and installation path
Project file storage path consistent with the best.
2. The version number
About version naming rules: the major version number subversion revision number
1. When the project early version, the version number is 0.1.0;
2. When the project during the partial modification or bug fixes, the major version number and minor version numbers are the same, revision number plus 1;
3. When the project on the basis of the original increase of some function, the same major version number, minor version number plus 1, revision number reset 0;
4. When carrying out a major project modification or partial correction accumulate more, and cause the project overall incidence global changes, the major version number
Plus 1, sub-version number and revision number is reset to 0;
5. Compile the version number is usually automatically generated by the compiler during compilation, we only define its form, if not from the compiler
Generated automatically, manually added value represents the current system time. Examples: V1.0.1 Build090305 Rel111123 other versions Rule: 1. (alphal) internal test version
This version represents the software is only a preliminary finished products, internal communication only within the group, the larger version of the software bug, limited internal testing.
Examples: V0.1.1 Build090305 alphal1 2. (beta) external Beta
This version with respect to the (alphal) version has been greatly improved, tested within the group, to eliminate a serious mistake, but still there are some flaws, need to go through extensive testing to further eliminate. Examples: V0.1.2 Build090305 beta1 3. demo demo
This section describes how to do only when the review or explain. Examples: V0.1.3 Build090305 demo1 4. release the final version
This version means "the final release version" in a series of test version after version after all, there will be a formal, under normal circumstances, release form of the word does not appear on the cover of the software, replaced by a symbol (Rel). When release release, must be released and the corresponding software version updates packaged together records issue. Examples: V1.0.1 Build090305 Rel111123
3. The rights restrictions
If the project itself needs to project team members for different access control, consider maintaining two projects: a project which has the corresponding source file, a file is compiled only.
4. The module version maintenance
1. File version generally do not need, but there should be a detailed update history; 2. Module version can be maintained, specifically distinguish different folders. |
|
|
|