[Tortoisesvn tutorial]

Tortoisesvn tutorial

Tortoisesvn is a SVN client.

1. Checkout Repository
First, you must check the repository of the server. The so-called checkout refers to obtaining the repository specified by the server. The checkout of all stored files is different from the checkout of visual source safe. vss checkout refers to locking a file. If you have used VSS before, pay attention to this question when learning subversion.
The specific Checkout Method is as follows:
Create an empty directory on the client, for example, F: \ project1. Right-click the Directory and select SVN checkout... from the pop-up menu ..., then fill in the "URL of repository" text box with the address of the Repository you want to connect to. This URL can be added as a browser. 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 server 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, an a.txt file will be displayed in the F: \ project1directory after checkout. In this example, because no files have been added to the server-side repository, no files are checkout in the F: \ project1 client.
In addition to the files and directories stored in the repository will be generated in F: \ project1 during checkout execution, a ". SVN "hidden directory, which is managed by subversion. Do not delete or manually change the files and directories. Now the files and directories in F: \ project1 are called the repository "working copy" short for "WC" and the operations for modifying, adding, and deleting files and directories in repository are as follows, all are implemented through the "working copy" operation.
After checkout is executed, a small State 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), which indicates that F: \ project1 is a repository "working copy", F: \ all files and directories in project1 also have similar status icons.

2.Add File 
Copy the file or directory to F: \ project1, right-click the file or directory, choose tortoisesvn-> Add, and click OK. If more than one file or directory is added, right-click the F: \ project1 node and choose tortoisesvn-> Add, you can 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 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 you execute commit to submit the modification 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.ObtainRepositoryThe latest version.
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. The file in F: \ 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 perform updateon 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 before executing the update command.

7. SubversionVersion Control Model
When you use subversion for version control, subversion records every modification (including adding, modifying, deleting, and so on) You make 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 to say, a revision is a "snapshot" of a repository at a certain moment ".
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.
Consider this situation:
James and James are the same 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 ), so he also executed the commit command on the modified file. At this time, the subversion will find that the modified file is the.txt file of revision10, 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 working copy to revision 11. at this time, subversionprompts that the job has been merged. The "typo" of the fifth line of the.txt file of Li Si has changed to "type ",
The tenth line is still the sheet. It is said that subversionhas merged the three modified sheets into the.txt file on the 4th page. 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 a.txt is not the tenth line, but the same as 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 tortoisesvn-> resolved tells 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
There is a ". SVN" directory 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, if F: \ project1 is a working copyfile, there are two a.txt and B .txt files under the directory, and a d.txt file exists in the cccfile. ". The SVN directory stores copies of files in the current directory after you last executed the update or commit command, for example, F: \ project1 \. a.txt and B .txt stored in SVN \ text-baseare copies of a.txt and B .txt under F: \ 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 discard the modification. 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 the sub-Scripts of F: \ project1 \ CCC \ d.txt(copy of d.txt 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. Previously, 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.Hybrid version 
The working copy of subversion is designed to coexist files of different versions. For example, F: \ project1 is a working copyobject. 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, and revision is for the entire file, but this description is used for convenience, please note, 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 earlier, you must ensure that you have modified the modification on the basis of the latest version of the file before submitting the modification,
In this case,

How can I know whether the current working copy file is in 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 file attributes
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. Later, Li Si also completed the modification. When he submitted the modification, the Subversion indicated that Li Si's file version was not the latest. Before commit, he should update a.jpg to the latest version, since image files cannot be merged, this means that there must be a change between Zhang San and Li Si that 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 file. Then, right-click the file and choose tortoisesvn-> Add to tell subversion to include the file in version control, click the right key on 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), and then click the set button "SVN: Needs-lock" to set the additional attributes. 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.Back to previous versions
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. The specific method to restore the status of the latest revison of repository to a previous revision is as follows:

Run the update command to update working copy to the latest revision, right-click working copy, and choose tortoisesvn-> show log, the pop-up log messages window displays all the revisions of the repository, selects the latest revision, and then holds down the Shift key, 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 is returned 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 copies in the ". SVN" directory are always copies of the latest revision files (here we are based on the assumption that no one else modifies 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 should 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.