Simple use of subersion and tortoisesvn

This article from: http://tech.it168.com/d/2008-06-14/200806142123416.shtml

[It168 TechnologyArticle]

This tutorial is intended for those who have never been familiar with subversion. Because the documentation provided by subversion is too long and comprehensive, the author may not be patient enough to read it (for example, when I first came into contact with subversion ), so I want to write a basic article, but I have encountered various aspects in the version control process (here it refers to what I have met, and I have not met many basic aspects of subversion, in terms of software engineering, there is no need ^ _ ^, and I have not written any of these aspects, let more people know about subversion and Use Subversion, an excellent version control tool (as if subversion is rarely used in China ). If there is something wrong with this article, please correct it. I am particularly grateful to the subversion.org.cn forum for answering my questions about lock and to the author of subversion for providing such an excellent version control tool.

1. Install Subversion

First install the subversion1.2.3 and graphical client TortoiseSVN-1.2.4.4479 (this version of tortoisesvn for subversion1.2.3 ). Subversion must be installed on both the server and client, and tortoisesvn only needs to be installed on the client.

2. Create a repository (store databases of various versions of the document)

Create an empty directory on the server, such as "C:" svnprojects "project1 ". The specific method to create a repository is: Under the Subversion installation directory, there is a svnadmin.exe file under the "binsubdirectory", enter the "bin directory in the DOS window, and execute" svnadmin create -- FS-type bdb C: "svnprojects" project1 ". Then you will find that there are several more directories and several files in the "C:" svnprojects "project1" directory that is originally empty. These directories and files are used to store databases of different versions of documents.

* ** In addition to using the command line to create a repository, you can also use tortoisesvn. However, tortoisesvn must be installed on the server. To create a repository, right-click the "C:" svnprojects "project1" directory and choose tortoisesvn-> Create repository here ...., in the displayed dialog box, select Berkeley database (bdb) and click OK.

3. Configure Repository

After a repository is created, you should configure the repository to control access permissions and add users of the repository. The "C:" svnprojects "project1" conf "svnserve. conf" file is the configuration file of this repository. It is a typical INI file, although it does not use ini as the extension. Open it in a text editor and you will see some text. The lines starting with "#" in this file are comments rows. Delete "#" of "# [general, "# anon-access = none" "# auth-access = write" "# password-DB = passwd" also deletes "#". Note that only the "#" character is deleted, do not delete all rows. "Anon-access = none" indicates that anonymous access to repository is not allowed, whether read or write operations. "Auth-access = write" indicates that the authenticated access allows write operations. Of course, read operations are more allowed. "Password-DB = passwd" indicates that the user name and password are stored in a file named passwd, which is also in the "C:" svnprojects "project1" conf "directory, open it in a text editor, delete the "#" character of "# [users]", add a new line at the end of the file, and write the username and password in the line, the format is "XXXX = YYYY". "XXXX" indicates the user name and "YYYY" indicates the password. Only one user can be set for one row. To set multiple users, start a new line.

4. Start the Subversion server

Subversion provides three server modes, one of which is described here. It is a lightweight server that comes with subversion. After the server is started, listen to client connection requests at Port 3690 on the server (this is by default, if you have otherProgramIt occupies port 3690. You can use the "-- listen-port" parameter to specify the server listening port ). The specific server startup method is: there is a svnserve.exe file under the "binsubdirectory" under the Subversion installation directory. This file can contain parameters when running. Two common parameters are "-d ", this parameter indicates that the server runs as a genie process until the program is manually terminated. Another parameter is "-R", which specifies the root path for the server process to find the repository. Go to the "bin directory" in the DOS window and run "Export svnserve.exe-d-r C:" svnprojects ". The server is started. The "-r c:" svnprojects "parameter is used when" SVN: // xxx/project1 "is used on the client (xxx can be the server host name, it can also be a server IP address. when accessing the server's repository, the server will know that the repository path you want to access is "C:" svnprojects "project1 ". If I have two completely unrelated projects for version control, create an empty directory "C:" svnprojects "project2" and create a repository in it, in this case, the client can use "SVN: // xxx/project2" to access the repository under "C:" svnprojects "project2. Now, the server configuration is complete.

5. Use of the Client

1. Checkout Repository

first, check the repository of the server. The so-called checkout is to obtain all the files stored in the repository specified by the server. The checkout and visual source safe checkout have different meanings. vss checkout refers to locking a file. If you have used VSS before, you must pay attention to this issue when learning subversion. The specific method of checkout is to create an empty directory on the client, for example, F: "project1
right-click the Directory and select SVN checkout... in the pop-up menu ..., enter the address of the Repository you want to connect to in the "URL of repository" text box. For the repository created in section 2 of this tutorial, the URL should be "SVN: // xxx/project1 "(xxx can be the server host name or IP address ).

Click OK. In the displayed authentication dialog box, enter the user name and password set in section 3 of the tutorial. Click OK to complete the repository checkout. For example, if there is an a.txt file in the repositoryon the server side, a.txt file will be displayed in the "project1directory" after checkout. In this example, because no file is added to the repository on the server, no file is checkout in the F: "project1 of the client. In addition to F: "project1 generates the files and directories stored in repository, a". SVN "hidden directory, which is managed by subversion. Do not delete or manually change the files and directories. Now F: "the files and directories in project1 are called the" working copy "abbreviation of" WC "in repository (this abbreviation is... Khan ). Subsequent modification, addition, and deletion operations on files and directories in repository are implemented through the "working copy" operation. After checkout is executed, a small status icon is attached to the lower left corner of the icon in the F: "project1 directory (when the file in the F:" project1 directory changes, this status icon also changes.) It indicates F: "project1 is a repository" working copy ", F: "All files and directories in project1 also have similar status icons.

2. Add a file

Copy the file or directory to be added to F: "project1, right-click the file or directory, and click tortoisesvn-> Add. Click OK. If more than one file or directory is added, right-click the F: "project1 and choose tortoisesvn-> Add to add multiple files or directories. The file status icon changes. The add command only tells the local "working copy" to include the file in version management and does not submit the change to the server. If you want others to see your changes to repository, you need to right-click F: "project1, SVN commit ..., submit your modifications to repository. The file status icon is also updated. Whether you add, modify, or delete files in "working copy", you must use the commit command to submit the modifications to the server-side repository if you want others to see your modifications.

3. Modify the file

After you modify a file in a text editor or IDE, the file status icon changes, right-click, SVN commit... submit the modification. Only after the modification is submitted by the commit operation will the modification be reflected in the repository on the server side.

4. delete an object

When deleting a file, select the file or directory to be deleted, right-click tortoisesvn-> delete, and submit the modification. Do not use the "delete" key to delete files. Otherwise, your modifications cannot be submitted. This is especially important for directory deletion.

5. Discard Modification

After you add, modify, or delete a file, you can right-click tortoisesvn-> revert, the files and directories in the local "working copy" will be restored to the state before your modification.

6. Get the latest version of repository

When a team is working on a development project, everyone is constantly updating the repository. You need to constantly update your "working copy" to obtain the latest project files. When we obtain the latest repository file for the first time, we use the checkout Command, which has been described earlier. When we get the latest file, we do not need to checkout. Instead, use the update command. In the preceding example, F: "project1 has become a" working copy "(by executing the checkout command). Now others have modified the repository, I want to reflect others' changes to my "working copy" by right-clicking the F: "project1 directory and SVN update. F: "The file in project1 is the latest version. Note: if there are modified files or deleted files in your "working copy" and these modifications have not been submitted, these files will not be updated during update. For example, if you have modified the.txt file under F: "project1and have not submitted any modifications, the.txt file will not be updated to the.txt file on the repositorywhen you update F:" project1. Therefore, if you want to discard all current modifications and update all files and directories under F: "project1 to the latest version, run the revert command on F:" project1 and then run the update command.

7. Subversion version Version Control Model

when you use subversion for version control, the Subversion records every modification (including adding, modifying, deleting, and so on) to the repository ), each time a repository is modified, a new revision (Revision version number) is generated. Different revisions represent the repository status at different times. Therefore, we can use this revision to return the repository status at any time, just like a time machine, that is, a revision is a "snapshot" of a repository at a certain time point ". Note: revision is not for a file or directory, but for the entire repository. Each time a repository is modified, revision increases by 1.

The Subversion version control model is called copy-Modify-Merge (copy-Modify-merge. Considering this situation: James and James are in the same department of the company. They jointly maintain the.txt file and perform version control on the file. Therefore, they put the file on a repository file to jointly maintain the file. At nine o'clock A.M. on Monday, James and James tried to modify the.txt file, so they simultaneously obtained the latest version (revision 10) of the file from repository and then modified the file. After three minutes, Michael first completed the modification. On the fifth line of the file, he modified the spelling of a word (changing typo to type ), therefore, John runs the commit command on the modified file and submits the modification to the repository on the server. In this case, the revision of repository is changed to 11. Six minutes later, Li Si also completed his modification. He modified the spelling of a word on the tenth line of the file (changed he to she ), therefore, he also executed the commit command on the modified file. At this time, the subversion will find that the File Modified by Li Si is the.txt file of revision 10, instead of the.txt file of the latest revision 11. Therefore, the Subversion prompts Li Si to update working copy to the latest version before submitting the modification, li Si executes the update command to update the working copy to the "typo" on the fifth line of the revision hosts file to "type", and the tenth line is "she". That is to say, the subversion has merged the three modified tokens into the.txt file of Li Si. Then, Li Si executes the commit command to submit his modifications to the tenth line (change he to she) to the repository on the server (generate Revision 12 ). However, such a merge may become more complex in some situations. For example, Li Si's modification to the.txt file is not the tenth line, but the same as that of Zhang San's modification to the fifth line, li Si changed "typo" to "typr" and submitted the modification. At this time, the subversion will prompt Li Si to update working copy to the latest version before submitting the modification, when the subversionmerges the.txt file of revision11and the.txt File Modified by Li Si, it is found that Li Si modified the fifth line, so he made the modification based on the statement. This kind of situation is called conflict(conflict between parties, the icon of the.txt file will become a yellow triangle. At this time, we can only rely on Li Si to determine whether the third line should be changed to "typr" or "type ". Right-click the.txt file and choose tortoisesvn-> resolved.
Tell subversion that conflict has been resolved. Then execute the commit command to submit the changes (generate Revision 12 ). The Subversion control ensures that all modifications made to the file are based on the latest version of the file.

8. ". SVN" Directory

A ". SVN" directory exists in each layer of the client working copy Directory, which is used for subversion management. Do not manually modify the files. This directory stores a copy of working copy (where the actual storage copy is F: "project1 ". SVN "text-base directory). For example: F:" project1 is a working copyfile. There are two a.txt and B .txt files under the directory, and a d.txt file in the cccfile. ". SVN stores copies of files in the current directory after you last executed the update or commit command, for example, F: "project1 ". SVN "The a.txt and B .txt stored in text-baseare copies of a.txt and B .txt under project1after the last update or commit command is executed. That is to say, all your modifications are based on the files stored in the ". SVN" directory. This mechanism allows us to restore the files in working copy to the state before modification without connecting to the network. Subversion's revert command is implemented using this mechanism. For example, if you modify the F: "project1" a.txt file, you have changed your mind and want to stop modifying the file. You can right-click tortoisesvn-> revert, the modified f: "project1" a.txt file will be F: "project1 ". in SVN "text-base, the.txt file is replaced by the sub-document, and a.txt is restored to the state before modification.
in working copy, each subdirectory has a ". SVN" directory, not only the top-level directory can have the ". SVN" directory. Therefore, F: "project1" CCC also has a ". SVN Directory, which stores a copy of F: "project1" CCC "d.txt's sub-document (d.txt is located in F:" project1 "CCC ". SVN "text-base ). That is to say, each ". SVN" directory stores only copies of "Files" in the same directory, but not copies of "directories. ". The SVN directory contains many important contents. Therefore, when deleting a file or directory, you must use tortoisesvn-> Delete instead of the "delete" key to delete the file or directory, especially for directory deletion.

9. Mixed version

The working copy of subversion is designed to coexist files of different versions. For example, F: "project1 is a working copyfile. The directory contains two files, a.txt and B .txt. Run the update command to update working copy to the latest version (Revision 24 ). At this time, both a.txt and B .txt revision are 24 (in fact, there is no revision for a single file. Revision is for the entire repository. Here it refers to the.txt and B .txt stored in revision24 of repository, but for convenience, please note that, the same below ). After that, you have modified a.txt and submitted the modification. Then, the revision of repository is changed to 25. Note that the update is not executed again, so the revision of your working copy is still 24. Now you have modified the B .txt file and submitted the modifications. Because revision25does not modify the B .txt file, you must modify the B .txt file based on the latest version of the B .txt file, so conflict will not appear. After you submit the B .txt modification, revision26 is generated. At this time, you will find that the.txt file in your working copyis not the.txt file in revision25, and the a.txt file in revision24. your B .txt file is the B .txt file in revision26. That is to say, when you commit, only the files submitted by you in your working copy are the latest version, and other files that have not been modified are not updated to the latest version. In this way, your working copyis formed by different revisionfiles (a.txt file of revision24and B .txt file of revision26 ). As mentioned above, you must ensure that you modify the file based on the latest version before submitting the modification. If this hybrid version is used, how can you know whether the file in the current working copy is the latest version? As mentioned above, the SVN directory contains a file named "entries", which records the revision of each file in the current working copy. Therefore, when you commit, the Subversion obtains the revision of the submitted file from the file, and compares it with the latest revision of the repository to see whether the modified file is based on the latest version of the file.

10. File Locking

As mentioned above, the version control model of subversion is a model called copy-Modify-Merge (copy-Modify-merge. This model works well in Version Control of text files, but some files that require version control are not text files, such as image files, this model cannot work normally in this case, because text files can be merged, while binary files cannot be merged. Therefore, from 1.2, subversion supports a version control model called lock-Modify-Unlock (lock-Modify-unlock. Visual source safe (VSS), the most common version control software in windows, adopts this model. This model requires that you first lock the file before modifying the file. In this case, the file cannot be modified and the lock will be released after modification, so that others can lock the file and modify it. To lock a file, click tortoisesvn-> get lock... and then click OK to lock the file. At this time, if another person wants to lock the file, the subversion will prompt him that the file has been locked. After modifying the file, right-click SVN commit ..., submit the changes. By default, the file will be unlocked when it is submitted. If you want to lock the file, select the keep lock check box in the dialog box that appears at commit.

11. Additional attributes of the file

In subversion, each file can have an additional property. Additional attributes describe the features of the file. Subversion has predefined some additional attributes (here, it only means that subversion has defined the "name" of some additional attributes, not that these attributes have been attached to the file, for example, by default, a text file does not contain any attributes at the beginning until an additional attribute is manually added to the file. You can also add custom attributes to the file. Subversion treats additional attributes just like the object content. When an object's additional attributes (ADD, change, and delete additional attributes) are modified, even if the object content is not modified, similarly, you can commit this file. Just like changing the file content, repository will also generate a new revision, so in a sense, subversion does not distinguish modification of the object's additional attributes from modification of the object's content. The object's additional attributes can be seen as a special object content. Subversion predefines several additional attributes. Here we only discuss the "SVN: Needs-lock" attribute, because it is related to a problem that will be generated by the file lock above. For other attributes, refer to the help documentation provided by subversion. In this situation, James and James want to modify the.jpg file of an image. When Michael wants to modify the file, he first locks the file and then modifies it. At the same time, Mr. Li also began to modify the file, however, when Li Si forgets to modify a non-text file, he should first lock the file. Zhang San first modified the file, so he submitted his modifications to the server. Merge to the latest version, because the image files cannot be merged, this means that there must be a change between Zhang San and Li Si will be voided. This problem can be avoided by applying the "SVN: Needs-lock" attribute. When a file has the "SVN: Needs-lock" attribute, when the file is not locked, the file icon is gray, indicates that the file is a read-only file (the Windows read-only attribute check box of the file is selected). This gray icon will remind the person who wants to modify the file, you should first lock the file before modifying it. After the file is locked, the read-only attribute of the file will be removed. Once the lock is released, the file icon will become gray and the file will become read-only. In this case, Li Si will avoid modifying the file when the file is not locked. To add the "SVN: Needs-lock" attribute to a non-text file, you must set it when you add the file to repository for the first time. Of course, you can add additional attributes to a file at any time, this is done to reduce the chance of the problem that Li Si encountered. The specific method is: first copy the.jpg file to the working copy, and then right-click the file, tortoisesvn-> Add, telling subversion to include the file in version control, right-click the file and select properties. In the displayed Properties dialog box, select the Subversion page. Select "SVN: Needs-lock" in the drop-down box, and fill in "*" in the text box below (in fact, it doesn't matter if you fill in anything here, as long as the file has "SVN: needs-Lock), click the set button, and set the "SVN: Needs-lock" additional attribute. Then run the commit command to submit the modification. When others execute updateat this time, a.jpg will be added to their working copy, and the file's additional attributes will also be obtained along with the file. We can see that a.jpg is dimmed, and the windows attribute of the file is read-only.

12. Return to the previous version

Because the Subversion records every modification to the repository, it is easy to get the status of the repository at a certain time point before. For example, the latest revision of repository is 56. Now I want to check the status of repository in revision24. You can right-click it in the local working copy, tortoisesvn-> update to revision ..., enter the revision number you want to reply to and click OK.

back to the previous version, there is another situation where I want to make the latest revision status of the repository the same as that of a previous revision. The above method is not suitable, the above method only replies the local working copy to the previous state, and the repository on the server does not return to the previous state. To restore the latest revison status of the repository to a previous revision, run the update command to update the working copy to the latest revision, and then right-click the working copy file, tortoisesvn-> show log. In the pop-up log messages window, all revisions of the repository are displayed. Select the latest revision, and then press shift, click the revision you want to reply to revision + 1 (for example, the latest revision of repository is 30, and you want to return the repository status to revision16, select revision30, press shift and select revision17, that is, select all revisions between revision17 and revision30 ). Right-click the selected revision and select "revert changes from these revision ". Click "yes" to return the status of working copy to the target revision. Note:
in this case, only working copy replies to the target revision, and then commit should be used to submit the changes, so that the latest repository status is the same as that of the target revision.

The two methods for replying to the previous version are completely different. The first method is to reply the entire working copy to a revision, that is, in this way, the working copy in ". the file copies in the svn directory are the same as those in the target revision. If you do not modify the file, you cannot execute the commit command. In the second method, the replicas in the svn directory are always copies of the latest revision files (Here we use the assumption that no one else has modified the repository after update ). This method is like Manually changing the state of the working copy file to the target revision, and submitting the modification after the modification.

13. View changes

Sometimes we modify many working copy files. These files are located in different subdirectories, so we can right-click the top directory of working copy and choose tortoisesvn-> check for modifications, the pop-up dialog box displays all the modifications you have made.

Another case is that our working copy has not executed the update command for a long time. We want to see which files in working copy have been modified, right-click the top-level directory of working copy, choose tortoisesvn-> check for modifications, and click check repository in the displayed dialog box, the modified files on the server are displayed. Another purpose of this method is to view the file lock. When you want to lock a file, you need to first check whether the file is locked by others, click the check repository button to display all the locked files in the server repository. If the file you want to lock is not included, it indicates that no one has locked the file.