The 1 client is divided into two command-line clients and GUI clients.
Tortoise SVN is the GUI client.
TortoiseSVN GUI program is called TortoiseProc.exe
2 TortoiseSVN After the installation is complete, you can right-click to see the SVN Checkout and TortoiseSVN options.
1) SVN Checkout is to download a project from the remote server, need to fill out the remote warehouse address, local check out the directory, if it is the first time, may also require a user name password.
After checking out, one is generated under the project root. SVN file.
. SVN this hidden directory records two key messages: The baseline version of the working file and the timestamp of the last update of the local copy, and do not manually modify or delete this. SVN hides the directory and the files inside!!, otherwise it will cause your local working copy (static attempt) to be corrupted and no longer operational.
2). Add (Add)
Under the test project file, create a new B.txt file, and submit it to the repository in the following 2 ways:
1. First mention the change list, then commit to the configuration library, select the new file, right-click on the SVN menu to execute the "ADD" action submitted to the "Change list", and then right-click on the SVN menu "svn commit" commit to the repository.
2. Do not submit to the list of changes, but directly in the Commit configuration library, select the file, right-click on the SVN menu to perform an "SVN Commit" operation.
3). Remove (delete)
If the deleted file is not yet in the repository, you can delete the file directly using the operating system's delete operation.
If the deleted file is in the repository, the deletion is as follows: Select the deleted file, right-click the SVN menu to perform a "delete" action, then select the parent directory of the deleted file, and right-click on the SVN menu to execute "SVN Commit".
2 or delete the file using the operating system Delete, then select the deleted file's parent directory, right-click on the SVN menu to execute "SVN Commit", select the deleted file in the change list.
4. Renaming (Rename)
Modify the filename, select the file or folder you want to rename, then right-click "Tortoisesvnàrename", enter the new name in the dialog box that pops up, click "OK" button, and submit the file or folder after the modified file name to the SVN server via "SVN commit".
5. SVN restore (svn Revert)
Right-click the file or folder you want to fallback, and select "Update to reversion ..." in the TortoiseSVN pop-up menu. For example, we have to go back to the 10th version only need to fill in revision the corresponding version number, and then click OK.
6. Checking for updates (check for modifications)
This feature can show that you have made the changes have not been submitted, this feature can not only see changes to the file change, all the changes can be seen, including adding files or directories, delete files or directories, moving files or directories, etc., if you click on the check repository, you can also see the version of the repository changes, You have not updated your local file as to which files have been changed by others
7. SVN updates (SVN update)
Update the local code consistent with the latest version of the SVN server, simply right-click on the folder you need to update or right-click on the blank in the file, select "SVN Update" (Get the content in the specified version, right-click on "Update to reversion" in the SVN menu) , you can do it.
7.1 How to resolve conflicting files
For each conflicting file subversion placed three files in your directory: the following:
Why would a conflict code be generated? The reason is very simple is because different people, at the same time modified the same file of the same place, when he submitted, I did not submit, I will not submit, this time we have to update, and then commit, if there is a conflict, it will generate the above 3 files.
The solution is as follows:
First we can look at the 1.txt code as follows:
<<<<<<<. Mine
aaaasdf11222333 Dderderder
=======
B>>>>>>>. R5
And then I get rid of the extra code, and 1.txt becomes this
aaaasdf11222333 Dderderder
Commits, or cannot be submitted, as follows:
Why. Because the conflict will produce the above three files, there are 3 files above the existence of the affirmation can not be submitted, the three file codes and explanations are as follows: 1.txt.mine is a pre-conflict file. You can look at the following content:
aaaasdf11222333 Dderderder
2.1.TXT.R4 is a pre-conflict local version file
The contents are as follows: aaaasdf11222333
3.1.TXT.R5 is the version that someone else has to commit before you
The contents are as follows: b
Among them, <<<<<<<<.mine ... the code between ======= is your own, and ======......>>>>>>>. R5 is the part of someone else's code that conflicts with you.
It is not difficult to understand why the conflict is such a strange thing, because you modify the same piece of code, of course, will create conflicts.
The solution is as follows: If I am now in the 1.txt conflict content is as follows:
<<<<<<<. Mine
6666666666666600000
=======
66666666666aaaaaaaaaa666
>>>>>>>. R16
Previously said <<<<<<< mine ... =======
...... The code between is the code that I modified before I produced the conflict,
======= .........>>>>>>>. R16 this middle ... The code is someone else with me conflict code part, from the above code can see Aaaaaaaaa is my colleague new, 00000 is I added later. Using the revert (rollback) operation, which indicates that the user has discarded their own update code, and then submitted directly, this time your code will be the server on the latest code, a user submitted by the new code, your code will not be committed, as follows:
Click the OK button to see the other three files are automatically deleted, 1.txt code into the following code:
66666666666aaaaaaaaaa666
That is, a user-submitted code, my own updated code needs to be copied in-person to commit a commit. If I now 3.txt generate conflict codes as follows:
<<<<<<<. Mine
333333338888888888888=======
3333cccccccccc3333>>>>>>>. R16
Through the 1th we know, 333333338888888888888 this content is I modified, no conflict before the content, 3333cccccccccc3333 this code is a user-submitted code, from the above learned that a user new content is CCCCCCC, And my new content is 8888888.
Then the second solution is as follows:
Select File, right-click Editconficts: This method requires the conflicting parties to negotiate after the code changes are unified before committing. Not only resolves the conflict but also ensures that the code is correct, because only one of the code is committed.
As shown in the figure above, the red part is the conflict code: theirs represents the current server-side of the latest code, mine represents its own modified code, merged represents the merged code. Right-click on the Red button to select: Use this text block can be used as the combined code
Let's talk about the situation where the important code is overwritten because of the conflict. When a conflict occurs, if the action is not correct, it can cause some code to be lost, and it is easy to restore the previous code.
Select File-Right-select Show log in this area you can see all the versions that were submitted before, find the version you want to restore right-click on the revert to this release to restore.
SVN commit (SVN commit)
SVN commits the changes made in the workspace, including changes to the contents of the file, additions to the file or directory, deletion, naming, moving, and so on. As shown in the following illustration:
8. Show logs (show log)
This feature allows you to find out who, when, and how those files in that directory were done, as shown in the following diagram:
9. Repository Browsing (repo-browser)
This feature is used to browse the library that needs to be viewed, right-click on the local folder, select Tortoisesvnàrepo-browser, enter the repository address in the popup dialog, and then enter the user name and password to see what you need to see the repository. Here you can also see who locked the files, as shown below:
3 SVN file Icon Description:
A newly checked work copy uses a green checkmark overload to indicate that the subversion status is normal.
After you start editing a file, the state becomes modified, and the icon reload becomes a red exclamation point. In this way, you can easily see that those files have been modified since you last updated the working copy and need to be submitted.
If a conflict occurs during the commit process, the icon becomes a yellow exclamation mark.
The plus sign tells you that a file or directory has been scheduled to be added to version control.
4 Creating a branch merge related action