Svn(subversion) is a version management tool that has emerged in recent years, and it is the successor of cvs. At present, most open source software uses svn as code version management software.

Use of the client

1. Check out the repository

First, check out the repository on the server side.

Check-out refers to obtaining all files stored in the repository specified by the server.

The meaning of this checkout is completely different from that of Visual Source Safe.

The checkout of VSS refers to locking the file. If you have used VSS before,

We must pay attention to this problem when learning subversion.

The specific checkout method is:

Create an empty directory on the client, for example: F:\Project 1.

Right-click the directory and select "SVN Check Out" ... in the pop-up menu.

Then fill in the address of the repository you want to connect to in the URL of repository text box.

This URL address can be added by browsing.

For the repository established in the second part of this tutorial,

The website address should be "svn://xxx/project 1".

(xxx can be the host name of the server or the ip address of the server).

Then click OK to pop up an authentication dialog box.

Enter the user name and password set in the third part of this tutorial.

Click OK to complete the checkout of the repository.

For example, there is an a.txt file in the server-side repository.

Then an a.txt file will also appear in the F:\Project 1 directory after checkout.

In this example, since no files have been added to the server-side repository,

So no files are checked out under the client's F:\Project 1.

In addition to generating files and directories stored in the repository of F:\Project 1,

Hidden directory of ". Svn "is also generated, which is managed by subversion.

Do not delete or manually change files and directories.

Now the files and directories in F:\Project 1 are called "working copies" of the resource pool, abbreviated as "WC".

This is short for ... Khan.

Future operations to modify, add and delete files and directories in the repository,

It is all achieved through the operation of this "working copy".

After performing checkout,

In the F:\Project 1 directory, you will see a small status icon in the lower left corner of the icon.

(This status icon will also change when the files in the F:\Project 1 directory change),

This means that F:\Project 1 is a "working copy" of a repository.

F: All files and directories in \ project1will have similar status icons.

Add file

Copy the file or directory to be added to F:\Project 1.

Then right-click the file or directory, Tortoisesvn->; Add and click OK.

If multiple files or directories are added,

Then don't click on any files in F:\Project 1.

Then right-click, TortoiseSVN-& gt；; Add,

You can add multiple files or directories.

The status icon of the file will change.

The Add command simply tells the local "working copy" to put the file into version management.

This change was not committed to the server.

If you want others to see your changes to the repository, you need to

Click the right mouse button under F:\Project 1 and SVN submits. ...

Commit your changes to the repository.

The status icon of the file will also be updated.

Whether you add, modify or delete files in the Working Copy,

If others want to see your revision,

You must Commit the changes to the server-side repository using the commit command.

alter file

After modifying a file with a text editor or IDE,

The status icon of the file changes,

Then right-click, SVN submits. ...

Commit the modification, and only after committing the modification,

Your changes will be reflected in the server-side repository.

delete a file

When deleting a file, select the file or directory to delete.

Right click, TortoiseSVN-& gt；; Delete and submit the modification.

Be careful not to use the "Delete" key to delete files, otherwise you will not be able to submit your changes.

This is especially important for deleting directories.

5. Give up modification

When you add, modify or delete a file, you decide to give up the modification.

You can right-click TortoiseSVN-& gt；; Reply,

Files and directories in the local "working copy" will be restored to the state before you modify them.

6. Get the latest version of the repository

When a team works together to develop a project,

Everyone is constantly updating the repository.

You need to constantly update your "working copy".

Get the latest files of the project.

When you first get the latest repository file,

We use the Checkout command introduced earlier.

You don't need to check out the latest documents in the future.

Please use the Update command instead.

According to the previous example, F:\Project 1 has become a "working copy".

Now that someone else has modified the repository (by executing the Checkout command),

I want to reflect other people's revisions in my "work copy".

The specific method is: right-click the F:\Project 1 directory,

The latest news of SVN. At this time, the file in F:\Project 1 is the latest version.

Please note that if there are modified files in your "working copy",

Or there are deleted files and these changes have not been committed.

These files will not be updated during the update process.

For example, modify the a.txt file under F:\Project 1

No changes have been committed, then,

When you update F:\Project 1,

The a.txt file will not be updated to the a.txt file on the repository.

So if you want to give up all the current changes,

And update all files and directories under F:\Project 1 to the latest version.

The Revert command should be executed on F:\Project 1 before the Update command.

7. Version control model of 7.subversion

When you use subversion for version control,

Subversion will record every modification you make to the repository (including addition, modification, deletion, etc.). ).

Every time the repository is modified, a new revision number is generated.

Different versions represent the state of the repository at different times.

Therefore, we can use this version to call the status of the repository at any time.

Just like a time machine, that is, a revised version.

Is a "snapshot" of the repository at a certain moment.

Note: Version is not specific to files or directories.

But for the entire repository.

Every time the repository is modified, the revision will increase 1.

Subversion's version control model 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.

They maintain a text file a.txt,

And controls the version of the file,

So they put this file in a warehouse and maintain it.

At 9: 00 a.m. on Monday, Zhang San and Li Si will modify the a.txt file at the same time.

So they also got the latest version of the file (revision 10) from the repository.

And then make changes. Three minutes later, Zhang Sanxian finished the revision.

He changed the spelling of a word in the fifth line of the document.

So Zhang San executed the Commit command on the modified file.

Commit the changes to the server-side repository.

At this point, the revision of the repository becomes 1 1.

Six minutes later, Li Si also finished his review.

He revised the spelling of a word in the tenth line of the document (changed He to She).

Therefore, he also executed the Commit command on the modified file.

At this point, Subversion will find that when committing changes,

The file modified by Li Si is a. txt file with version 10.

Instead of the latest version of 1 1 a.txt file.

Therefore, Subversion reminds Li Si that before submitting the revision,

You should update the working copy to the latest version first.

Li Si executes the update command to update the working copy to version 1 1.

Subversion will prompt that the merge has been completed.

The "typo" in the fifth line of Li Si's a.txt file was changed to "type".

The tenth line is still "she", which means that Subversion has "merged" Zhang San's changes into Li Si's a.txt file.

After that, Li Si will execute tHe Commit command again, and then he can modify the tenth line (change He to She).

Submitted to the server-side repository (generated revision 12).

However, this merger will become more complicated in some cases.

For example, Li Si's revision of a.txt file is not the tenth line.

But like Zhang San, modify the text in the fifth line.

Li Si changed "Typo" to "Typpr" and submitted the amendment.

Subversion will prompt Li Si to submit the changes.

You should update the working copy to the latest version first.

Li Si executes the update command to update the working copy to version 1 1.

At this point, Subversion will compare the a.txt file of version 1 1 with the.

When merging the a.txt file modified by Li Si, I found that Li Si also modified the fifth line.

Subversion cannot be judged as Li Si's modification ("Tpyr").

Correct or Zhang San's modification ("type") is correct,

Because they are all modified on the basis of 10 version a.txt

This situation is called conflict,

The icon of the. txt file will turn into a yellow triangle.

At this time, Li Si can only judge for himself whether the third line should be changed to "Typpr" or "Type".

When Li Si confirms the modification, right-click the a.txt file, Tortoisesvn->; resolved

Tell Subversion that the conflict has been resolved.

At this point, execute the Commit command to submit the modification (generate the revised version 12).

Subversion ensures that all changes you make to the file are based on the latest version of the file.

8."8."。 Svn "directory

"There will be. Svn "directory of each layer of client working copy.

Subversion uses this directory for management.

Do not manually modify the files in it.

This directory stores copies of working copies.

(The actual storage location of the copy is the directory F: \ Project 1 \. SVN \ text-base)，

For example, F:\Project 1 is a working copy.

There are two files a.txt and b.txt in this directory, and there is a subdirectory ccc.

There is also a d.txt file under the subdirectory ccc.

". The "svn" directory stores a copy of the file in the current directory after the last update or commit command.

For example: a.txt and b.txt stored in f: \ Project 1 \. SVN \ text base.

Is a copy of a.txt and b.txt under F:\project 1 after the latest update or submission of the command.

In other words, all the changes you make are based on the data stored in the. Svn "directory.

This mechanism allows us to connect to the network,

Restore the files in the working copy to the state before modification.

Subversion's Revert command is realized by using this mechanism.

For example, if you modify the F:\project 1\a.txt file,

At this time, you changed your mind and wanted to give up modifying the file.

You can right-click TortoiseSVN-& gt；; Reply,

The F:\project 1\a.txt file has been modified.

It will be replaced with a copy of a. txt file in f: \ Project 1 \. SVN \ text base.

In order to restore a.txt to the state before modification.

"There will be. Working copies in each subdirectory under the svn directory.

It's not just top-level directories that have ".". Svn "directory.

Therefore, there is also a kind of ". F:\project 1\ccc under svn "directory.

This directory stores a copy of f: \ project1\ ccc \ d.txt.

(a copy of d.txt is located at f: \ project 1 \ CCC \. SVN \ text-base)。

In other words, every one. " Svn "directory only stores copies of" files "in the same level directory.

Without storing a copy of the directory. ". The svn directory contains many important contents.

So when deleting a file or directory,

TortoiseSVN-& gt； Delete,

You can't use the "Delete" key to delete files or directories, especially directories.

9. Mixed version

The working copy of Subversion is designed to contain different versions of files.

For example, F:\Project 1 is a working copy.

There are two files a.txt and b.txt in this directory.

Execute the update command to update the working copy to the latest version (revision 24).

At this point, the versions of a.txt and b.txt are both 24.

(In fact, a single document has not been revised.

The revision is for the entire repository,

This refers to a.txt and b.txt stored in the repository version 24.

But for convenience, please pay attention to this description, the same below).

Later, your colleague revised a.txt and submitted the revision.

At this point, the version of the repository becomes 25.

Please note that you did not perform the update again at this time.

So your working copy version is still 24.

At this time, you modified the b.txt file and submitted the modification.

Because Revision25 didn't modify the b.txt file,

Therefore, your modifications to the b.txt file are based on the latest version of the b.txt file.

So there will be no conflict.

When you submit changes to b.txt, version 26 will be generated.

At this point, you will find that the a.txt file in your working copy is not the a.txt file in Revision25.

It is also the a.txt file of Revision24, and your b.txt file is the b.txt file of Revision26.

In other words, when you submit, only those files you submitted in the working copy are the latest versions.

Other unmodified files will not be updated to the latest version.

This will cause your working copy to be composed of different revision files.

(a.txt file of version 24 and b.txt file of version 26).

As I said before, before submitting the revision, you must make sure that you have revised the file on the basis of the latest version.

If in the case of this mixed version,

How do I know if the file in the current working copy is the latest version?

There is a file named "Entry" in the aforementioned "Entry". Svn "directory.

This file records the revisions of each file in the current working copy.

So when you submit, Subversion will get the revised version of the file you submitted from the file.

By comparing with the latest version of Repository, you can know whether the file you modified is based on the latest version of the file.

10. File lock

As mentioned earlier, Subversion's version control model is a version control model called copy-modify-merge.

(Copy-Modify-Merge) model.

This model works well in version control of text files,

But some files that need version control are not text files.

Such as an image file, in which case the model cannot work normally.

Because text files can be merged, binary files cannot be merged.

So Subversion supports a method called lock-modify-unlock from 1.2.

(Lock-Modify-Unlock) Version control model.

This model is adopted by Visual Source Safe(VSS), the most commonly used version control software under Windows.

This mode requires that files should be locked before being modified.

Then you can modify it. At this time, others will not be able to modify the file.

Release the lock after modification so that others can lock the file and then modify it.

The method of locking files is: tortoisesvn->; Get locked ... Click the OK button again.

The file is locked at this time.

At this point, if someone else wants to lock the file,

Subversion will prompt him that the file has been locked by others.

When you finish modifying the file, and then right-click, SVN submits. ...

Commit the changes, and by default, the file will be unlocked when submitting.

If you still want to lock the file, please select the "Keep Lock" check box in the pop-up dialog box when submitting.

Additional properties of 1 1. file

In Subversion, every file has something called an additional attribute.

Additional attributes describe some features of the file.

Subversion predefines some additional properties.

(This only means that Subversion has defined the names of some additional properties.

This does not mean that these properties have been attached to the file.

For example, by default, a text file initially contains no attributes.

Until additional attributes are artificially added to the file),

You can add custom attributes to a file.

Subversion treats additional attributes just like file content.

When modifying additional attributes of a file (adding, changing and deleting additional attributes),

Even if the contents of the file have not been modified,

You can also submit the file, just like changing the contents of the file.

The repository will also generate a new revision,

So in a sense,

Subversion will not treat the modification of additional attributes of files differently from the modification of file contents.

The additional attributes of a file can be regarded as a special file content.

Subversion predefines several additional properties,

Only the "svn:needs-lock" attribute is discussed here.

Because it is related to the problem caused by a file lock above.

For other properties, please refer to the help documentation that comes with Subversion.

In view of this situation,

Zhang San and Li Si also want to modify a picture file in a.jpg.

Zhang San locks the file before modifying it.

At the same time, Li Si also began to modify the documents.

But Li Si forgot that non-text files should be locked first when they are modified.

Zhang San first completed the modification of the file, so Zhang San submitted his own modification to the server.

After that, Li Si also completed the revision. When he submitted the revised edition,

Subversion prompts that the version of Lisi file is not the latest.

A.jpg should be updated to the latest version before submission.

Because picture files cannot be merged,

This means that there must be one person's revision between Zhang San and Li Si.

Applying the "svn:needs-lock" attribute can avoid this problem.

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 read-only (the check box of the Windows read-only property of the file is selected).

This gray icon will remind people who want to modify the file.

You should lock the file before modifying it.

After the file is locked, the read-only attribute of the file will be deleted.

Once unlocked, the file icon will turn gray again.

The file will become read-only.

In this case, Li Si will avoid modifying the file when it is unlocked.

Add "svn:needs-lock" to the non-text file.

Property should be set when the file is first added to the repository,

Of course, additional attributes can be added to the file at any time.

This is done to reduce the probability that Li Si will encounter problems.

The specific method is:

First, copy the a.jpg file to the working copy.

Then right-click the file,

TortoiseSVN-& gt； Add, tell Subversion to put the file under version control,

Then right-click the file and select Properties.

Select Subversion page in the pop-up properties dialog box.

Select "svn:needs-lock" in the drop-down box.

And fill in * in the text box below.

(Actually, it doesn't matter what you fill in here, as long as the file has the additional attribute of "svn:needs-lock"),

Then click the Set button, and the additional attribute "svn:needs-lock" will be set.

Then execute the Commit command to commit the changes.

At this time, when others perform the update,

A.jpg will be added to their working copy.

And additional attributes of the file will be obtained together with the file.

You can see that a.jpg's icon is gray at this time.

The Windows attribute of this file is also read-only.

12. Go back to the previous version

Because Subversion will record every modification you make to the repository,

Therefore, it is easy to get the state of the repository at a previous moment.

For example, the latest version of the repository is 56.

At this point, I want to see the status of the version 24 repository.

You can right-click the local working copy.

TortoiseSVN-& gt； Update to version,

Then enter the version number to which you want to reply, and click OK.

Back to the previous version, there is another situation, I want to put the repository's

The status of the latest revision is exactly the same as that of the previous revision.

The above method is not suitable,

The above method only restores the local working copy to its previous state.

The server-side repository has not returned to its previous state.

The specific method to restore the latest version state of the repository to the previous version state is:

Execute the update command to update the working copy to the latest version.

Then right-click the working copy,

TortoiseSVN-& gt； Show logs,

The pop-up log message window will display all revisions of the repository.

Select the latest version, and then hold down the Shift key.

Then click the revised version+1 to reply.

(For example, the latest version of the repository is 30.

You want to restore the state of the repository to version 16.

Then select Revision30 and hold down the Shift key.

Select version 17,

That is, all versions between 17 and 30 are selected.

Then right-click the selected revision,

Select Restore changes from these revisions.

Click the "Yes" button again, and the status of the working copy will be restored to the target version.

Please note that only the working copy is restored to the target version at this time.

After that, you should Commit the changes using commit.

In this way, the latest state of the repository is the same as that of the target revision.

These two ways of reverting to the previous version are completely different.

The first method is to restore the entire working copy to the revised version.

In other words, in this way, a copy of the file is stored in the ". The "svn" directory in the working copy is exactly the same as the target version.

If you do not modify the file at this time, you will not be able to execute the submit command.

In the second way, the client in the working copy

This copy is stored in ". The svn directory is always a copy of the latest version of the file.

(Here we assume that no one else has modified this repository since the update).

This is similar to manually changing the file status of the working copy to the target version.

Submit the modification after modification.

13. View and modify

Sometimes we will modify many files of the working copy.

These files are located in different subdirectories, so we can right-click the top-level directory of the working copy.

TortoiseSVN-& gt； Check and modify,

The pop-up dialog box will show all the details of your modification.

In another case, our working copy has not executed the update command for a long time.

We would like to see which files in the working copy have been modified.

At this point, you can right-click the top-level directory of the working copy.

TortoiseSVN-& gt； Check and modify,

After clicking the Check Repository button in the pop-up dialog box,

The file modified on the server side will be displayed.

Another purpose of this method is to check the locking of files,

When you want to lock a file, you want to see if it is locked by others.

Click the Check Repository button to display all the locked files in the server-side repository.

If the file you want to lock is not in it, it means that the file is not locked at present.