Use of tortoisesvn Client

Tortoisesvn is a visual client program ----- easy to use. SVN is the command line mode. : TortoiseSVN-1.1.3-UNICODE_svn-1.1.3.msi

(This file name is NT/2 k/XP version) Official Website: http://www.tortoisesvn.org

There are also Chinese addresses. Other packages: the installation packages for independent servers, Web servers, command line methods, Python support, and so on must be provided. You can refer to the svn website instructions to download and install the packages. For more information, see the help files after installation... Principles to be determined: 1. Create a database ----------- and determine the database backup location. I use different databases for different projects. Cause ------------- so yes
Put the database and backup together. It also implies that the database of the program and its backup are bundled with the project. It also facilitates the management of the entire project, and the entire project also needs regular management such as backup.
2. Create a working directory. ------ Determine the working directory of the write program. 3. Create an ignore list. ----------- Such as readme. At the same time, it is a good choice to set your compiler to output the compilation file to another folder instead of the working directory. Attachment: [1] Permission questions about modifying a diary. Because it is used by itself, no security issues are considered. The version diary modification permission is unavailable after tortoisesvn is installed. Solution: locate the hooks directory in the repository and copy the pre-revprop-change.tmpl as a pre-revprop-change.bat
Then modify the last content in the pre-revprop-change.bat file to: Set repos = % 1
Set REV = % 2
Set User = % 3
Set propname = % 4
Set action = % 5
If/I not '% propname %' = 'svn: log' goto error_propname
If/I not '% action %' = 'M' goto error_action
Set bisempty = true
For/F "tokens = *" % G in ('Find/V "" ') do set bisempty = false
If '% bisempty %' = 'true' goto error_empty
Goto: EOF

: Error_empty
Echo empty SVN: log properties are not allowed.> & 2
Goto error_exit: error_propname
Echo only changes to SVN: log revision properties are allowed.> & 2
Goto error_exit: error_action
Echo only modifications to SVN: log revision properties are allowed.> & 2
Goto error_exit: error_exit
Exit/B 1

 

 

Use of tortoisesvn Client

1. Checkout Repository

First, you need to 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,
Pay attention to this issue 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 ...,
Enter the address of the Repository you want to connect to in the URL of repository text box,
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 host name or IP address of the server ).
Click OK to bring up an authentication dialog box,
Enter the username and password set in section 3 of the tutorial.
Click OK to complete the repository checkout.
For example, if the server repositoryhas an a.txt file,
After checkout, an a.txt file will be displayed in the directory F:/project1.
In this example, because no files have been added to the repository on the server,
Therefore, no file is checkout in the F:/project1 of the client.
In addition to the files and directories stored in the repository generated in F:/project1,
An implicit directory named ". SVN" is also generated, 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 "working copy" abbreviation of "WC" in repository"
(This short name is... Khan ).
Modify, add, and delete files and directories in repository in the future,
All are implemented through the "working copy" operation.
After checkout is executed,
A small status icon is attached to the icon in the lower left corner of the F:/project1 directory.
(When the file in the F:/project1 directory changes, the 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, choose tortoisesvn-> Add, and click OK.
If more than one file or directory is added,
Do not place any files in the F:/project1 point,
Right-click 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,
The change is not submitted to the server,
If you want others to see your changes to repository, you need
Right-click F:/project1, SVN commit ...,
Submit your modifications to repository.
The file status icon is also updated.
After you add, modify, or delete a file in "working copy,
If you want others to see your changes,
You must use the commit command to submit the modifications to the repository on the server.

3. Modify the file

After modifying a file using a text editor or IDE,
The file status icon changes,
Right-click SVN commit...
Submit the modification. Only after the modification is submitted by executing commit,
Your modifications will be reflected in the repository on the server.

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 decide to discard the modification,
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 works 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 you obtain the latest repository file for the first time,
We use the checkout Command, which has been described earlier,
You do not need to use checkout to obtain the latest file later.
Instead, use the update command.
In the preceding example, F:/project1 has become a "working copy ".
(By executing the checkout command), others have modified the repository,
I want to reflect others' changes to my "working copy,
The specific method is: Right-click the F:/project1 directory,
SVN update. In this case, the file in F:/project1 is the latest version.
NOTE: If your "working copy" contains modified files,
Or there are deleted files, and these modifications have not been submitted,
These files will not be updated during update.
For example, if you modify the.txt file under F:/project1,
No changes have been submitted, so,
When you update F:/project1,
A.txt files are not updated to a.txt files on repository.
So if you want to discard all current modifications,
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. Subversion version Version Control Model

When you use subversion for version control,
The Subversion records every modification you make to the repository (including adding, modifying, deleting, and so on ),
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
It is a "snapshot" of the 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 version control model of subversion is called copy-Modify-merge.
(Copy-Modify-merge) model.
Consider this situation:
Zhang San and Li Si are colleagues in the same department of the company,
Their common maintenance and maintenance documents a.txt,
And control the version of the file,
Therefore, they put the file on a repository to jointly maintain the file.
At nine o'clock A.M. on Monday, James and James wish to modify the.txt file,
So they also obtained the latest version (revision 10) of the file from repository ),
Then modify. After three minutes, James first completed the modification,
He modified the spelling of a word on the fifth line of the file (Change typo to type ),
Therefore, Michael runs the commit command on the modified file,
Submit the modification to the server-side repository.
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 (change he to she ),
So he also executed the commit command on the modified file,
At this time, the subversion will find when submitting the modification,
The modified file is the.txt file of revision10,
Instead of the.txt file of the latest revision 11.
Therefore, subversion prompts Li Si before submitting the modification,
Update working copy to the latest version,
Run the update command to update working copy to revision 11,
At this time, the subversion will prompt that the merge has been completed,
The "typo" of the fifth line of the.txt file 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 modify the tenth line (change he to she)
Submitted to the repository on the server (generate Revision 12 ).
However, such a merge may become more complex in some situations,
For example, the modification to the.txt file by Li Si is not the tenth line,
Instead, the words on the fifth line are modified in the same way as those on Michael Zhang,
Li Si changed "typo" to "typr" and submitted the modification,
At this time, the subversion will prompt Li Si before submitting the modification,
Update working copy to the latest version,
Run the update command to update working copy to revision 11,
In this case, subversionmaps the.txt file of revision11with
When the.txt File Modified by Li Si is merged, it is found that Li Si's modification is also the fifth line,
Therefore, subversion cannot determine that it was modified by Li Si ("tpyr ")
Correct or the modification ("type") of Michael Jacob is correct,
Because they are all modified based on a.txt of revision10.
This situation is called conflict (conflict ),
The icon in the.txt file is changed to 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

There is a ". SVN" directory in each layer of the client working copy directory,
This directory is used for subversion management.
Do not manually modify the files.
This directory stores a copy of working copy.
(The actual storage copy is in the F:/project1/. SVN/Text-base Directory ),
For example, F:/project1 is a working copy,
The directory contains two files a.txt and B .txt, and a sub-directory CCC,
A d.txt file exists in the project ccc.
The ". SVN" directory stores copies of files in the current directory after you last executed the update or commit command,
For example, F:/project1/. SVN/text-basestored a.txt and B .txt
This is a copy 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 avoid network connection,
Restore the files in working copy to the state before modification.
Subversion's revert command is implemented using this mechanism.
For example, if you modified the F:/project1/a.txt file,
Now you have changed your mind to give up modifying the file,
You can right-click tortoisesvn-> revert,
Modified F:/project1/a.txt File
It will be replaced by a copy of the.txt file in F:/project1/. SVN/text-base,
Restore a.txt to the status before modification.
In working copy, each subdirectory contains a ". SVN" directory,
Not only the top-level directory has the ". SVN" directory.
Therefore, F:/project1/CCC also has a ". SVN" directory,
This directory stores copies of F:/project1/CCC/d.txt
(The copy of d.txt is located at F:/project1/CCC/. SVN/Text-base ).
That is to say, each ". SVN" directory stores only copies of "Files" in the same directory,
Instead of storing "directory" copies. The ". SVN" directory contains many important contents,
Therefore, when deleting a file or directory,
Tortoisesvn-> Delete,
You cannot use the "delete" key to delete files or directories, especially directories.

9. Mixed version

The working copy of subversion is designed to coexist files of different versions.
For example, F:/project1 is a working copy,
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,
This indicates the.txt and B .txt stored in revision24of repository,
But for convenience, please note that, the same below ).
After that, you modified a.txt and submitted the modification,
Then the revision of repository is changed to 25.
Note that you have not executed update again,
Therefore, 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,
For this reason, you must modify the B .txt file based on the latest B .txt file version,
Therefore, 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,
The suffix is also the.txt file of revision24, and your B .txt file is the B .txt file of revision26.
That is to say, when you commit, only the files submitted by you in your working copy are the latest version,
Other files that have not been modified are not updated to the latest version.
In this way, your working copy is composed of different revision files.
(A.txt file of revision24and B .txt file of revision26 ).
As mentioned above, you must ensure that you modify the file on the latest version before submitting the modification,
In this case,
How can I know whether the current working copy file is in the latest version?
In the ". SVN" directory mentioned above, there is a file named "entries,
This file records the revision of each file in the current working copy,
Therefore, when you commit, the subversion will obtain the revision of the submitted file from the file,
Compare with the latest revision of repository to see if the file you modified is based on the latest version of the file.

10. File Locking

As mentioned earlier, the version control model of subversion is called copy-Modify-merge.
(Copy-Modify-merge) model.
This model works well in Version Control of text files,
However, some files that require version control are not text files,
For example, for image files, this model cannot work normally under such circumstances,
Because text files can be merged, binary files cannot be merged.
Therefore, subversion 1.2 supports a lock-Modify-Unlock method.
(Lock-Modify-unlock) version control model.
Visual source safe (VSS), the most common version control software in windows, adopts this model.
This model requires that the file be locked before modification to a file,
Then, the file cannot be modified,
After modification, release the lock so that others can lock the file and then modify it.
To lock a file, click tortoisesvn-> get lock... and then click OK,
In this case, the file is locked.
At this time, if someone else wants to lock the file,
Subversion will prompt him that the file has been locked.
After modifying the file, right-click SVN commit ...,
Submit the modification. By default, the file will be unlocked upon submission,
If you want to still lock the file, select the check box for keep lock in the dialog box that appears during 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, only the subversion has defined the "name" of some additional attributes ",
This does not mean that these attributes have been attached to the file,
For example, by default, text files do not contain any attributes at the beginning,
Until you manually add additional attributes to the file ),
You can also add custom attributes to a file.
Subversion treats additional attributes just like file content,
When an object's additional attributes are modified (ADD, change, and delete ),
Even if the file content is not modified,
You can also commit this file, just like changing the file content,
Repository will also generate a new revision,
So in a sense,
The Subversion does not differentiate the modification of the object's additional attributes and the modification of the object's content,
The additional attributes of a file can be considered as a special file content.
Subversion predefines several additional attributes,
Here we will only discuss the "SVN: Needs-lock" attribute,
Because it is related to a problem that the above file lock will produce.
For other attributes, refer to the help documentation provided by subversion.
Consider this situation,
James and James wish to modify a.jpg,
John first locks the file and then modifies it,
Li Si 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 prompts that the file version of Li Si is not the latest,
Before commit, update a.jpg to the latest version,
Because 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 icon of the file is gray,
Indicates that the file is a read-only file (the Windows read-only attribute check box of the file is selected ),
The gray icon reminds 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 turns gray again,
The file will also become read-only.
In this case, Li Si will avoid modifying the file when the file is not locked.
Add "SVN: Needs-lock" to non-text files"
The attribute should be set when the file is added to the 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 working copy,
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 ",
Enter "*" in the text box below.
(In fact, it doesn't matter if you fill in anything here, as long as the file has the "SVN: Needs-lock" additional attribute ),
Click the set button and set the additional attributes of "SVN: Needs-lock.
Then run the commit command to submit the modification.
When others perform the update,
A.jpg will be added to their working copy,
And the additional attributes of the file will also be obtained along with the file.
The a.jpg icon is gray,
The Windows attribute of the file is also read-only.

12. Return to the previous version

Because the Subversion records every modification to the repository,
Therefore, it is easy to obtain the status of the repository at a previous time point.
For example, the latest revision of repository is 56,
Now I want to see the repository status during revision24,
You can right-click 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 Repository
The status of the latest revision is the same as that of a previous revision,
The method above is not suitable,
The above method only replies the local working copy to the previous state,
The repository on the server does not return to the previous status.
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 in working copy,
Tortoisesvn-> show log,
The pop-up log messages window displays all the revisions of the repository,
Select the latest revision, and then press shift,
Click the revision of revision + 1 you want to reply.
(For example, the latest revision of repository is 30,
You want to return the repository status to revision16,
Select revision30 and press shift,
Select revision17,
That is to say, select all revisions between revision17 and revision30 ).
Right-click the selected revision,
Select revert changes from these revision ".
Click "yes" to return the status of working copy to the target revision.
Note: At this time, only working copy is returned to the target revision,
Then, use commit to submit the changes,
In this way, the latest repository status is the same as that of the target revision.
The two methods for replying to previous versions are completely different,
The first method is to reply the entire working copy to a revision,
That is to say, in this way, the file copies in the ". SVN" directory in working copy 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 assume 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,
After the modification, submit 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,
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 directory of working copy,
Tortoisesvn-> check for modifications,
In the displayed dialog box, click check repository,
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 has been locked by others,
Click Check repository to display all locked files on the server,
If the file you want to lock is not in this area, it indicates that no one is locked.