[Software Engineering Technology-program version control] use of svn-basic knowledge, server construction and daily use and maintenance of client

Author: gnuhpc
Source: http://www.cnblogs.com/gnuhpc/

 

This article comprehensively revised several blogs on the Internet and the materials on hand. The original source is unknown. If you have any copyright issues, please contact me in time and provide the original text link. Here we use a Windows client and server as an example. Linux corresponds to the same principle.

I. Basic Knowledge:

1. Why SVN?

· When programmers write programs, each program generates many different versions.

· This requires the programmer to effectively manage the code and quickly and accurately retrieve the corresponding version as needed.

· Any place where frequent information changes need to be managed. This is the stage of subversion.

2. What is subversion?

· Sub version (SVN for short) is a version management tool.

· Subversion is a free/open-source version control system.

· A group of files are stored in the central version library, recording every file and directory Modification

· Subversion can access its version library through the network

· Any number of clients can connect to the version library to read and write these files.

· By writing, others can see this information and read data to see others' modifications

3. What are the features of subversion?

· Version-based directory: Subversion implements a "virtual" version-based file system that can track directory tree changes.

· Real version history: you can add a new file with a clean history.

· Atomic commit: allows users to build a logical block for submission and modification to prevent some modifications from being submitted to the version library.

· Versionized metadata: each file or directory has a set of attributes-keys and their values.

· Optional Network Layer: There is an abstract concept in terms of version library access, which facilitates people to implement new network mechanisms.

· Consistent data operations: files are based on the binary file difference algorithm.

· Efficient branch and Tag: when creating a branch and tag, it only copies the entire project and uses a mechanism similar to hard link.

· Modifyable: Implemented by a series of well-shared C libraries with well-defined APIs

4. What is the principle of subversion?

Lock-Unlock

Copy-Modify-Merge

The subversion mainly uses copy-Modify-merge model, and lock-Unlock model to manage data sharing.

5. What is the basic workflow of subversion?

II,SVNServer Setup and Configuration:

1. Start: After visual SVN server is installed, run visual SVN server manger. The following is the startup interface:

2. Add a code library [repository]: for example:

Create a new code library as shown in, and enter the code library name in the text box shown in the following figure:

Note: If the checkbox in is selected, the trunk, branches, and tags subdirectories will be created under the code base startkit. If not selected, only the empty code base startkit will be created.

Click OK to create the code library.

3. Security Settings:

Right-click users on the left side:

Enter the above information and click OK to create a user. Follow the steps above to add users Example 1, tester1, and manager1 respectively. Now, let's start adding these users to the project we just created:

Click "add...", select the user we just added in, and click OK:

Note: You may have noticed groups. Yes, you can also create a group, add users to each group, and then authorize the group. The operation is relatively simple and skipped here.

Authorize the user or group as follows:

Click "OK". The above user has different permissions to access the code base.

Ii. Usage of SVN client-basic usage of tortoisesvn

1. import source code to the svn Server

If you want to check the source code of the Project startkit into the code library on the svn server, right-click the startkit folder. The right-click menu is shown in:

Click Import to bring up the following form, where the http://zt.net.henu.edu.cn/is the server name, SVN is the root directory of the code repository, startkit is a code library we created on the svn Server:

Note: the checkbox in the lower-left corner is useless when the source code is checked in for the first time. However, it is very useful when you submit code later.

Click "OK". The following form is displayed, requiring creden:

In the above form, enter the user name and password, and click OK:

As shown in, the source code has been successfully imported to the svn server. At this time, the team members can export the source code from the svn server to their own machine.

2. Export the source code to the local machine.

It is the operation to extract a copy of a directory from the version library to a directory on the local machine, called checkout. This operation is the basis of work.

Create a folder on the local machine, right-click checkout, and the following form is displayed:

In the text box at URL of repository: Enter the address of the code library in SVN server. By default, click OK to export the source code.

Note: The checkout depth option in contains four options: export all, check only the sub-directories and files at the next level, export only files, and check out empty projects. The default option is the first item. In the above example, we can also access the code library in the Web way, enter http://zt.net.henu.edu.cn/svn/StartKit/ in the browser

In this case, a dialog box is displayed, asking you to enter the user name and password. After verification, you can view the content in the code library.

Open the Directory and you can see the folder structure as shown in:

Once you have made any changes to the file or folder, the display image of the file or folder will change. I modified two of these files:

Take a look at the image corresponding to different States:

3. Submit the modified file to the svn server.

For example, the imageinfo. CS and newsinfo. CS files in the model file are modified.

Note: When submitting the source code to the server, make sure that the local code is the latest version. Otherwise, the submission may fail or cause version conflict.

Right-click the model folder or right-click the blank area under the model file, and click SVN commit... The following form is displayed:

Click OK to bring up the following form:

The function of commit is not only to upload files, but to compare it with files on the server. If you update a file and someone on the server updates the file, and it is an update after you checkout, then it will try to integrate your update with others' updates (merge). If the automatic merge fails, then report conflict, you must manually write your own merge, that is, to write your updates in conflict with those of others. It is best to fill in the log information during the commit, so that others can see what your updates are written. This is equivalent to uploading files and explaining the modifications made by myself. log is very important when many people work together.

4. Add a new file to the svn Server

Suppose we add a new class file userinfo. CS under the model file, right-click the file userinfo. CS, and click tortoisesvn =>> Add. The following window is displayed:

Select userinfo. CS file, click the OK button, so that the file is not submitted to the svn server, but the file is marked as a file in the source code library, and its status is changed. Then, we need to submit the svn commit file to the code library on the svn server. The steps for adding folders are the same.

5. Update the local code to be consistent with the latest version on the svn server.

This is also very simple. You just need to right-click the folder to be updated or right-click the blank space under the file and click SVN update. Before submitting the changes, you must run the update operation to merge the new changes made by others.

Note: The update operation may fail due to version conflict. You can use merge [merge] or another method to solve the problem. Alternatively, the update operation may fail because the get lock is locked, this is to unlock the [release lock] first ]. If the local code has been modified, merge will be performed first like commit, and conflict will be reported if the Code fails. In addition, if someone else deletes a file, you will also be deleted locally after the update.

6. Rename the file or folder and submit the modification to the svn server.

Right-click the file or folder to be renamed, and click tortisesvn => rename ..., Enter a new name in the pop-up form and click OK. This method does not directly rename the file or folder, but marks the name of the file or folder as the name after renaming. We also need to submit it to the svn server using SVN commit to rename it.

7. delete files or folders and submit the changes to the svn server.

The easiest way is to directly delete files or folders and use SVN commit to submit updates to the svn server. Another method is to right-click the file or folder you want to delete> tortoisesvn => Delete to delete it. This method is not directly deleted, the state of the file or folder is set to delete. We also need to use SVN commit to submit it to the svn server before deleting it.

8. How to switch between the branches or trunk of the same project
Use tortoise svn-> switch and enter the branch or trunk URL in the URL.

9. Compare the differences between the two versions

· If you want to see more information about your local replicas, you only need to right-click the resource manager and select tortoisesvn → compare the differences.

· If you want to view the modifications to the main program (if you develop it on the branch) or the modifications to a branch (if you develop it on the trunk), you can right-click the main program and choose from the shortcut menu. Press the Shift key while clicking the file, and then select tortoisesvn → URL comparison. In the displayed dialog box, the URL address of the version to be compared with your local version is displayed.

10. How to Create a branch or tag for an SVN master project

The basic concept of a branch: The development line is independent of the other line. If you review the history, you can find that the two lines share the same history. A branch always starts from a backup, start from there and develop your own unique history.

SVN branch management actually saves different branches with different files. Therefore, when you obtain the new version, you will find that the latest files of different branches will also be obtained. The tag creation operation is equivalent to copying the current code version to other places, and then starting from this place for new development, with no interference with the original version.

· Select the file for which you want to generate the branch, right-click it, and select [branch/mark...]

· In the [to URL (t)] input box, rename the file as your branch file name, enter the log information to facilitate differentiation, and click "OK.

· The SVN repository copies a specified file named after you, but the new branch file name cannot be found in your local directory, to update your file to your branch, You must select a file, right-click it, and select [switch...]. select the file you want to rename and click OK. In this way, your local file is associated with the Branch file. Don't be surprised, the file name displayed on the local directory is still the old file name.

11. Conflict Resolution

When a file conflict occurs, SVN creates three files that are not subject to version control. If the files to be merged can be merged, a conflict record is left inside the file. For example, the conflicted file is plugin. c. If the base version is 1458 and the head is 1459, three temporary files are generated: plugin. c. mine, plugin. c. r1458, plugin. c. r1459,

Solution: A. manually modify the conflicted file B. Discard your changes. In practice, the solution is flexible and generally needs to be discussed with others

Note: Since these three files are created after update, after update, the base Directory of the working copy has changed to the updated version, so abandoning your changes will return to the new version. If the revert method is not used to resolve the conflict, the three temporary files will be retained and the subversion will think that the conflict is not resolved. Therefore, run resolved to tell SVN to resolve the conflict or delete the temporary file.

Iii. Use of the svn client in Linux:

1. Checkout:

Syntax: checkout (CO) URL [@ rev]... [path]

You can specify the checkout version. The default checkout operation is for the head version. In most cases, we need the head version. However, if you need a previous version, you can use-R (-- Revision) the parameter is in the form of "@ version number ".

Example:

·... -R 1452 detects version 1452. If yes

·... -R {""} will check the version closest to this date

·... /Trunk @ 1452 the same effect as 1st examples

Recursion and non-recursion,-N: No recursion (only for top-level Directories); otherwise, directory recursion (default, commonly used)

· Example 1: SVN Co SVN: // 218.94.9.38/svnrepos/skizcorp/trunk create a trunk directory in the current directory, which is a working copy

· Example 2: SVN Co SVN: // localhost/torm I:/projects/TORM: the Torm directory will be created in the I:/projects/directory to store the working copy

2. Update:

Syntax: Update (up) [path...]

The update process is used to synchronize changes to the version Library to the local device.

· Example 1: up directly updates the work copy to the latest version (head version)

· Example 2: update up-r 2007 to version 2007

· Example 3: up Doc/design only updates files under DOC/Design

-R and-N parameters are still useful.

Update modifies the base version of the updated directory. The base version of a file is the version copied to the file stored in the management directory. SVN. Revert will make the file back to the base version.

During the update operation, SVN prints the status of the affected files, including the following:

· A added

· D deleted

· U updated

· C conflict

· G merged

Note: If the prompt "C" indicates a conflict, you can use the "status" command to add the "-U" parameter to predict the conflict.

3. Revert:

Revert means to discard modifications to a file and restore the file content to the same version as the base version, that is, to restore the file to the unmodified status.

Syntax: Revert file/path

Example:

· Example 1: Revert ABC. c discards all modifications to ABC. C.

· Example 2 revert src/edu/nju/pojo discard the modification of all files in this directory

Iv. Notes:

1. In fact, from the time you migrate the source code to the svn server, data and files of each version can be moved out at any time even if you have deleted them.

2. When submitting source code to the svn server, do not submit folders such as bin and OBJ; otherwise, it will be very troublesome. Except for the bin directory of the web project, the DLL generated by referencing other projects in the bin directory of the web project does not need to be submitted.

3. for third-party libraries or assembly, do not simply reference them from their installation location. Instead, add a library directory under your solution and copy the required assembly or library file to this directory, then reference from the library directory.

4. Regarding the difference between checkout and export, when you want to release or compile it, it is best to use export. It will not introduce SVN additional files, so that the file structure looks clean. When you need to modify and submit the code, you can use checkout to create a local work zone. The code that checkout sends to somewhere will be monitored by tortoisesvn, the files in can enjoy various SVN services.

5. If you need to rename or move the file with a green check box, do not use the Windows function. Right-click them and tortoisesvn will have corresponding operations. Imagine that these files are no longer your local stuff. Tortoise must be aware of every action:

· Add a file to SVN version control and use the Add command

· Remove from version control and use the delete (RM, remove) command

· Move or rename, and use the move (rename) command

· Copy: Use the Copy command

· Create a directory and use the mkdir command

·......

6. If you regret modifying a file, right-click it and select revert. It will change back to the last checkut, or revert the entire project to any previous version.

7. note when using commit: if multiple files need to be submitted at the same time and the files are under different directories, click commit in the top directory of these files, tortoisesvn searches the clicked directory and all the files under the directory, and lists the modified files in the list. Check the files in the list carefully to determine which files need to be updated. If you do not need to update a file that has changed, you only need to right-click the file and choose restore; in case of file conflict (conflict: the file to be submitted has been changed by others and submitted to the version Library), you must enable the conflict resolution function.

8. For the three directories branches, tags, and trunk, it is not necessary to subversion, but a good habit of Team Development summarized. The usage is as follows:

· Developers submit all new features to the backbone. Daily modifications are submitted to/trunk: New features, bug fixes, and others.

· The trunk is copied to the "publish" branch. When the team determines that the software is ready for release (for example, version 1.0),/trunk will be copied to/branches/1.0.

· The project team continues to work in parallel, one team starts to perform rigorous tests on the branches, and the other team continues the new work at/trunk (for example, prepare for 2.0 ), if a bug is found at any location, the bug fix needs to be shipped back and forth. However, this process sometimes ends. For example, the Branch is already "stuck" for the final test before release.

· The Branch has been tagged and released. when the test is completed,/branches/1.0 has been copied to/tags/1.0.0 as a reference snapshot. This tag is packaged and released to the customer.

· Multiple branch maintenance. When version 2.0 continues to work on/trunk, bug fixes continue to be shipped from/trunk to/branches/1.0. If sufficient bug fixes are accumulated, the management department decides to release version 1.0.1: copy/branches/1.0 to/tags/1.0.1, And the tag is packaged and published.

· When the initial repository is created, these three directories are created and all code is put into/trunk. For example, to import the code under the project1 directory to repository, the project1 structure is: project1/branches, project1/tags, project1/trunk, project1/trunk/food. c, project1/trunk/egg. PC ......, Import the project1 directory to repository to create the initial database. Then, the export is returned to project1 as the local working directory.

9. Inspection modification:

· The status command can be used to check the copy status.

· The diff command can be used to check the changed content.

10. SVN Development Mode (reproduced)

Subversion has a standard directory structure.
For example, if the project is proj and the svn address is SVN: // proj/, the standard SVN layout is

SVN: // proj/| +-trunk +-branches +-tags

This is a standard layout. trunk is the main development directory, branches is the branch Development Directory, and tags is the tag archive directory (cannot be modified ). However, SVN does not have a clear specification on how to use these directories, but it is still a habit of users.
There are two methods to use these development directories. I focus more on software products (such as FreeBSD), because the development model of the Internet is completely different.
The first method is to use trunk as the main development directory.
Generally, all of our development is based on trunk. When a version/release development ends (development, testing, documentation, installation program, packaging, etc, the code is frozen (as defined by humans, it can be managed through hooks ). Tag based on the currently frozen code library. When the development task of the next version/stage starts, development continues in trunk.
If you find bugs in the previous release version or urgent functional requirements, and the Development version being developed cannot meet the time requirements, in this case, you need to modify the previous version. The Branch should be developed based on the tag corresponding to the release version.
For example, if you have just released 1.0 and are developing 2.0, You must fix the bug on the basis of 1.0.
Chronological order

1. 1.0 code frozen after development

2. Tag release1.0 Based on frozen trunk
The directory structure is
SVN: // proj/
+ Trunk/(freeze)
+ Branches/
+ Tags/
+ Tag_release_1.0 (copy from trunk)

3. Development started in 2.0. trunk is the development version of 2.0 at this time.

4. The bug 1.0 is found and needs to be modified. Branch is implemented based on the tag 1.0.
The directory structure is
SVN: // proj/
+ Trunk/(Dev 2.0)
+ Branches/
+ Dev_1.0_bugfix (copy from tag/release_1.0)
+ Tags/
+ Release_1.0 (copy from trunk)

5. 1.0 bugfix development in 1.0 bugfix branch and 2.0 development in trunk

6. After 1.0 bugfix is complete, perform release based on the branch of dev_1.0_bugfix.

7. Select the dev_1.0_bugfix branch merge back to trunk as needed (when to perform this step, based on the actual situation)

This is a very standard development model, and many companies adopt this model for development. Trunk is always the main development directory.
The second method is to develop each other in the branch of each release. trunk is only used for release.
In this development mode, trunk does not undertake specific development tasks. At the beginning of a development task of a version/stage, a new Development Branch is created based on the version already release, and develop based on this branch. In the above example, the timing relation is.

1. 1.0 development, and dev1.0 Branch
Directory structure
SVN: // proj/
+ Trunk/(not responsible for development tasks)
+ Branches/
+ Dev_1.0 (copy from trunk)
+ Tags/

2. 1.0 Development completed, merge dev1.0 to trunk
Directory structure
SVN: // proj/
+ Trunk/(merge from Branch dev_1.0)
+ Branches/
+ Dev_1.0 (development task ended, freeze)
+ Tags/

3. Tag 1.0 based on trunk
Directory structure
SVN: // proj/
+ Trunk/(merge from Branch dev_1.0)
+ Branches/
+ Dev_1.0 (development task ended, freeze)
+ Tags/
+ Tag_release_1.0 (copy from trunk)

4. 1.0 development, as the dev2.0 Branch
Directory structure
SVN: // proj/
+ Trunk/
+ Branches/
+ Dev_1.0 (development task ended, freeze)
+ Dev_2.0 (for 2.0 development)
+ Tags/
+ Tag_release_1.0 (copy from trunk)

5. Fixed bugs in 1.0 directly on the dev1.0 branch.
Directory structure
SVN: // proj/
+ Trunk/
+ Branches/
+ Dev_1.0 (1.0 bugfix)
+ Dev_2.0 (for 2.0 development)
+ Tags/
+ Tag_release_1.0 (copy from trunk)

6. Selective code merge

This is actually a distributed development. When each part is relatively independent (functional), you can open multiple Dev branches for development, so that each person/group will not affect each other. For example, dev_2.0_search and dev_2.0_cache. But Merge is a very painful thing.
Note that the sixth step is the selective merge, which can return dev_1.0 (used for bugfix) and dev_2.0 (used for development in the new version) to trunk after the development of MySQL 2.0. Or, run dev_1.0 merge to dev_2.0 for testing, and then merge returns to trunk.
The two methods have their own advantages and disadvantages. The first method is to obtain a pure dev_2.0 Development Branch, while the second method is more secure, because testing is required.
The above are the two development modes I have mentioned. Which one is better. Here, we will give a rough description of their respective advantages and disadvantages.
The first development mode (trunk is mainly developed and centralized ):
Advantage: simple management
Disadvantage: when there are many development modules and a large number of developers/small teams, conflicts may easily occur, affecting the development of the other party. Because all the changes may touch the other party's changes.
The second development mode (main branch development, distributed ):
Advantages: independent development is not easy to affect each other.
Disadvantages: complicated management, complicated merge, and easy to die.