TortoiseSVN Using Tutorials

TortoiseSVN Using Tutorials

TORTOISESVN is an SVN client.

1.Checkout Repository
First of all, to checkout server-side repository, so-called checkout means to obtain the server-side designated repository. All files stored this checkout and visual Source safe checkout are completely different, VSS checkout refers to locking a file, if you have previously used VSS, this problem must be noted when learning subversion.
The specific way to checkout is:
Create a new empty directory on the client, for example: F:\Project1 Right-click on the directory, select SVN Checkout ... in the pop-up menu, and then fill in the URL of Repository text box with the address of the Repository you want to connect to, This URL address can be added by browsing. For the second section of this tutorial, the Repository,url should be "svn://xxx/project1" (XXX can be the server-side hostname or the server-side IP address). Then click OK to bring up an authentication dialog, enter the user name and password set in section three of the tutorial. Click OK after the completion of the repository checkout. For example: There is a a.txt file in the server side repository, then a a.txt file will appear in the F:\Project1 directory after checkout. In this case, the server-side repository has not yet added any files, so no files are checkout on the client's F:\Project1.
Execution checkout In addition to the F:\PROJECT1 generated repository stored files and directories, there will also be a ". SVN" implicit directory, the directory is managed by subversion, do not delete or manually change the files and directories. Now the files and directories in the F:\Project1 is called repository "Working copy" shorthand "WC" after the repository file and directory modifications, add, delete operations, are through the "Working copy" Implementation of the operation.
When the Checkout finishes executing, you will find that the icon in the F:\Project1 directory has a small status icon attached to it (the status icon changes when the file in the F:\Project1 directory changes), which indicates f:\ Project1 is a repository "working Copy", and all files and directories in F:\Project1 will have similar status icons.

2.Add File
Copy the file or directory you want to add to F:\Project1, then right-click on the file or directory, Tortoisesvn->add, and OK. If you add more than one file or directory, you can add multiple files or directories by not clicking any files in the F:\Project1 midpoint and then right-tortoisesvn->add.
The status icon for the file is then changed. The add command just tells The local "working Copy" to include the file in version management, and does not submit this change to the server side, if you want others to see your changes to Repository, you need to right-click on the F:\Project1, SVN Commit ... , submit your changes to Repository. The status icon for the file is also updated. Whether you add, modify, or delete files within the working Copy, you must submit the changes to the server-side repository by using the commit command if you want others to see your changes.

3.Modify a file
After modifying the file with a text editor or IDE, the file's status icon changes, then right-click, SVN Commit ... Commit the changes, and the changes you make will be reflected in the server-side repository only after committing the commit changes.

4.Deleting Files
When deleting a file, select the file or directory you want to delete, right-click, Tortoisesvn->delete, and submit the changes. Note Do not use the "delete" key to delete the file, or you will not be able to submit your changes. This is especially important for directory deletions.

5.Discard Changes
When you add, modify, delete the file, decide to discard the changes, you can right-click, Tortoisesvn->revert, the local "working Copy" in the files and directories will revert to the state before you modify.

6.GetRepositorythe latest version
When a team is working on a project, everyone is constantly updating the repository, and you need to constantly update your "working Copy"
To get the latest files for the project. When the first time to obtain the latest repository file, we use the Checkout command, which has been introduced, and later to obtain the latest files will not be checkout. Instead, use the update command.

Then the previous example, when F:\Project1 has become a "working copy" (by executing the checkout command), now others have changed the repository, I want to reflect the other people's changes in my "working Copy", The specific method is: Right-click on the F:\Project1 directory, SVN Update. At this point the files in F:\Project1 are the latest version.
Note that these files will not be updated during the update process if you have modified files in your working Copy, or if you have files that have been deleted, and have not committed these changes.
For example, if you modify the F:\Project1 a.txt file, and you have not submitted the changes, the A.txt file will not be updated to repository files on a.txt when you update F:\Project1. Therefore, if you want to discard all current changes and update all files and directories under F:\Project1 to the latest version, you should perform the update command on the F: \project1 execution revert command first.

7.subversionthe version control model
When you use Subversion for versioning, subversion records every modification you make to repository (including additions, modifications, deletions, and so on), creating a new revision (revision number) every time repository is modified. Different revision represent the state of repository at different times, so we can use this revision to return to the state of repository at any moment, just like a time machine, which means that a revision is repository in a moment A "snapshot" of the tick.
Note: Revision is not for a file or directory, but for the entire repository. Each time the repository,revision is modified, it will increase by 1.
The version control model of subversion is a model called Copy-modify-merge (copy-Modify-merge).
Consider this situation:
Zhang San and Li Si are colleagues in the same department of the company, they co-maintain a text file A.txt, and the file version control, so they put the file on a repository to co-maintain the file.
Monday 9 o'clock in the morning, Zhang San and John Doe also wanted to make changes to the A.txt file, so they took the latest version of the file (Revision 10) from repository and then made the changes. After three minutes, Zhang San first changed the spelling of a word in the fifth line of the file (changing typo to type), so Zhang San executes a commit on the modified file and commits the modification to the server-side repository. Then repository's revision becomes 11. Six minutes later, John Doe also completed his changes, he modified the file on line tenth on the spelling of a word (he was changed to she), so he also executed a commit to the modified file, subversion will be found when committing changes, John Doe modified files are Revision10 a.txt files, not the latest revision 11 a.txt files. As a result, Subversion prompts John Doe before committing the changes, the working copy should be updated to the latest version, Li IV executes the update command to update working copy to revision 11, then Subversion will be prompted to complete the merge, The "Typo" in line fifth of John Doe's A.txt file has become "Type",
Line tenth or "She" means that Subversion has "merged" Zhang San's changes into John Doe's A.txt file. John Doe then executes the commit command to commit his modification to line tenth (change he to She) to the server-side repository (Generate revision 12).
But this kind of merging can become more complicated in some cases,
For example: John Doe to a.txt file modification is not the tenth line, but with Zhang San also modify the fifth line of words, John Doe the "Typo" to "TYPR", and commit the changes, Subversion will prompt John Doe before committing the changes, you should first update working copy to the latest version , the working copy is updated to revision 11 by the Update command, and when subversion merges the Revision11 a.txt file with John Doe modified A.txt file, it is found that the same fifth row was modified by the Li Four. Subversion cannot judge whether the John Doe ("Tpyr") is correct or Zhang San ("Type") correct, as they are all modifications made on the a.txt basis of REVISION10. This is called conflict (conflict), and the icon for the A.txt file becomes a yellow triangle. At this point, can only rely on John Doe himself to determine whether the third line should be modified to "TYPR" or "Type". When John Doe determines the modification, right-click on the a.txt file and Tortoisesvn->resolved tells Subversion that the conflict has been resolved. Then execute the commit command to commit the modification (generate revision 12). This control of Subversion ensures that the changes you make to your files are based on the latest version of the file.

8. ". SVN"Catalogue
There will be an ". SVN" directory in each layer of the client working copy, which is the directory where subversion is managed. Do not manually modify the files in them. This directory stores a copy of working copy (where the actual storage copy is the F:\project1\.svn\text-base directory),
For example: F:\Project1 is a working Copy, the directory has two files a.txt and b.txt there is a subdirectory CCC, sub-directory CCC also has a d.txt file. The ". SVN" Directory stores a copy of the files in the current directory after you last executed the update or commit command, such as the a.txt and F:\project1\.svn\text-base stored in the B.txt is a copy of A.txt and B.txt under F:\project1 after the last update or commit command has been executed. This means that the changes you make are based on those files that are stored in the ". SVN" directory. This mechanism allows us to restore the files in working copy to the State before the modification without connecting to the network.
The revert command of Subversion is implemented using this mechanism. For example, you modify the F:\project1\a.txt file, then you change your mind to discard the changes to the file, you can right-click, Tortoisesvn->revert, modified F:\project1\a.txt file will be f:\ PROJECT1\.SVN a copy of the A.txt file in \text-base, allowing A.txt to revert to the pre-modified state. There will be an ". SVN" directory under each subdirectory in working copy, not only the top-level directory but the ". SVN" directory. Therefore, there is also an ". SVN" directory under F:\PROJECT1\CCC, which stores a copy of F:\project1\ccc\d.txt (D.txt's copy is located in F:\project1\ccc\.svn \text-base). This means that each ". SVN" Directory stores only "copies of files" in the sibling directory, not the "directory" copy. The ". SVN" Directory has a lot of important content, so before you delete a file or directory, you must use Tortoisesvn->delete, and you cannot delete the file or directory with the "delete" key, especially the deletion of the directory.

9.Mixed Version
Subversion's working copy is designed as a form of coexistence of files that can contain different versions. For example, F:\Project1 is a working Copy, which has two files A.txt and b.txt. Execute the UPDATE command to update working copy to the latest version (Revision 24). At this time, a.txt and B.txt revision are 24 (in fact, for a single file does not exist revision,revision for the whole repository, This refers to the a.txt and b.txt stored by the repository Revision24, but in order to facilitate the use of this description, please note that the same below). Then your colleague modifies the A.txt and commits the changes, and repository's revision becomes 25. Note that you did not perform the Update again, so your working copy's revision is still 24. Then you modify the B.txt file and submit the changes. Because Revision25 does not modify the B.txt file, your B.txt file is modified based on the latest version of the B.txt file, so there is no conflict. When you submit b.txt changes, the REVISION26 is generated. At this point you will find your working copy of a.txt file is not a.txt file in Revision25, it's Revision24 a.txt file and your b.txt file is Revision26 b.txt file. That is, when you commit, only the files you submit in your working copy are the latest versions, and other files that are not modified are not updated to the latest version. This causes your working copy to be composed of different revision files (Revision24 a.txt files and Revision26 b.txt files). As mentioned earlier, you must make sure that you are modifying the latest version of the file before committing the changes.
In the case of this mixed version,

How do I know if the file in the current working copy is the latest version?
In the previous ". SVN" directory, there is a file named "entries" that records the revision of each file in the current working copy, so when you commit, Subversion will take the revision of your submission from the file and compare it to the latest revision of repository to see if the file you modified is based on the latest version of the file.

.Locking of files
As I said earlier, the version control model of subversion is a model called Copy-modify-merge (copy-Modify-merge). This model works fine when versioning text files, but some files that need to be versioned are not text files, such as image files, which do not work properly in this case, because text files can be merged and binaries cannot be merged. So subversion started from 1.2 to support a version control model called Lock-modify-unlock (lock-Modify-unlock). The most common version control software under Windows Visual Source Safe (VSS) is the use of this model. This model requires that before a file is modified to lock the file before it can be modified, the other person will not be able to modify the file, when the changes are finished and then release the lock, so that others can lock the file, and then modify. The way to lock a file is: Tortoisesvn->get lock ... Click the OK button again and the file lock is completed. At this point, if the other person wants to lock the file, subversion will prompt him that the file has been locked by someone else. When you finish modifying the file, then right-click, SVN commit ..., the commit will be modified, by default, the file will be unlocked when committed, and if you want to still lock the file, select the Keep lock check box in the dialog box that pops up when you commit.

One by one .additional properties of the file
        in subversion, each file can have something called an attached property. Attached properties describe some of the features that the file has. Subversion has pre-defined some additional properties (this means that subversion has already defined "names" for some attached properties, not that they have been attached to a file, for example, by default, the text file does not contain any properties at first). Until you manually add additional properties to the file, and you can add a custom property to the file. Subversion treats attached properties as if it were a file, and when the attached properties of a file are modified (add, change, delete attached properties), even if the contents of the file are not modified, the file can also be commit, as if the contents of the file were changed, and repository will generate a new revision, so in a sense, subversion does not discriminate between the file's additional properties and changes in the contents of the file, the attached properties of the file can be regarded as a special kind of file content. Subversion pre-defines several additional properties, which are discussed only in the "Svn:needs-lock" attribute, because it is related to a problem with the file lock that we have above. Other properties can refer to the help documentation that was brought with subversion. Considering this situation, Zhang San and John Doe also want to make a change to a picture file a.jpg, Zhang San change the file to lock it, and then modify it, and John Doe also began to modify the file, but John Doe forgot to modify the non-text file should first lock the file. Zhang San first modified the file, so Zhang San submitted his changes to the server. After that, John Doe also completed the changes, when he submitted the changes, Subversion prompt John Doe file version is not up-to-date, before committing should be updated a.jpg to the latest version, because the picture file can not be merged, which means that there must be a person between Zhang San and John Doe changes will be void. You can avoid this problem by applying the "Svn:needs-lock" property. When a file has the "Svn:needs-lock" attribute, the file's icon is grayed out when it is not locked, indicating that the file is a read-only file (the check box for the file's Windows read-only property is checked), and the gray icon reminds the person who wants to modify the file. You should lock the file first before modifying the file. After locking the file, the read-only attribute of the file is removed, and once the lock is released, the file's icon becomes grayed out and the file becomes read-only. John Doe In this case, you will avoid making changes to the file when the file is not locked. Adding "svn:need" to non-text filesThe S-lock property should be set when the file is first added to Repository, and, of course, a file can add additional properties at any time to reduce the chance that the problem encountered by Li four will occur.

The specific methods are:
First copy the a.jpg file to working copy, then right-click on the file, Tortoisesvn->add, tell subversion to include the file in version control, then right-click on the file and select Properties. In the pop-up Properties dialog box, select the Subversion page. In the drop-down box, select "Svn:needs-lock" and fill in the text box below "*" (in fact there is nothing to fill in, as long as the file has "Svn:needs-lock" attached property on the line), then click the Set button "Svn:needs-lock" The attached property is set. Then execute the commit command to commit the modification. When the other person executes the update, A.jpg is added to their working copy, and the attached properties of the file are also obtained along with the file. You can see that the a.jpg icon is grayed out, and the Windows properties of the file are read-only.

.back to the previous version
Because subversion records every change you make to Repository, it's easy to get the state of repository at a time before. For example: Now repository the latest revision is 56, then I want to see repository in the REVISION24 state, you can click on the local working copy right, tortoisesvn->update to Revision., then enter the Revision number you want to reply to, and click OK button. Back to the previous version there is another situation is I want to repository the state of the latest revision and a previous revision the state of the same, the above method is not suitable, the above method is just the local working copy back to the previous state, The server-side repository does not go back to its previous state. The specific way to revert the state of repository's latest revison to the state of a previous revision is:

        perform the update command first to update working copy to the latest revision, and then right-click in working Copy. Tortoisesvn->show log, the pop-up log Messages window will display all Revision of the repository, select the latest Revision, then hold down the SHIFT key, then click the revision+ you want to reply to 1 of the revision (such as Repository's latest revision is 30, you want to return the status of repository to Revision16, then select Revision30, and then hold down the SHIFT key, select Revision17, This means that all revision between REVISION17 and Revision30 are selected). Then right-click on the selected revision and select "Revert changes from these revision". Click the Yes button again to revert the status of working copy to the target revision. Note that at this point, only working copy replies to the target revision, and then commits the modification with commit, so that repository the latest state is the same as the status of the target revision. The two ways to revert to a previous version are different, and the first is to revert the entire working copy to a revision, which means that the copy of the file stored in the ". SVN" directory working copy is identical to the target revision. If you do not modify the file at this time, you will not be able to execute the commit command. And the second way the client working in copy

The copy of the. SVN directory is always the most recent copy of the revision file (here we are based on the assumption that no one else has modified the repository after the update). It's like we're going to manually modify the working copy's file state to the target revision and commit the changes after the change.


View Changes
Sometimes we modify many of the working copy files in different subdirectories, we can right-click on working copy's top-level directory, Tortoisesvn->check for modifications, A popup dialog will show you all the details of the changes you have made. Another situation 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, then you can right-click on working copy's top-level directory, tortoisesvn- >check for modifications, after clicking the Check Repository button in the popup dialog box, the file that has been modified on the server side is displayed. The method also has a purpose is to view the file lock, when you want to lock a file, you want to see if the file has been locked, click the Check Repository button will show the server side repository all locked files, if you want to lock the file is not here, That means no one is currently locked out of the file.

TortoiseSVN Using Tutorials