Subversion version Version Control (3)-Basic Concepts

I. Subversion Repositories

The Subversion version Version Control warehouse (repository) is no different from other version control systems. Unlike Working Copies, subversion repository is an abstract entity that can be used by subversion tools and libraries for almost proprietary operations. Many users interact with subversion based on work copies. Therefore, we will focus on the operations of work copies in subversion.

Ii. Any number of documents and directories submitted by the revisions subversion client (COMMIT) are based on separate atomic transaction operations. In short, either the version library accepts all the modifications or does not accept any modifications. Subversion maintains atomicity for program crashes and system crashes. Each time the version Library receives a commit command, it creates a new state for the file system tree, which is called revision. Each revision is assigned a unique natural number representation, and subsequent revision numbers are larger than the previous revision numbers. The revision value of a newly created repository is 0, and it does not contain anything except an empty root directory. As shown in, imagine a revision array composed of numbers, counting from 0 and extending from left to right. Each revision has a file system tree. Each file system tree is a snapshot of the version library after receiving the commit command. Figure 1 file system tree changed over time 3. Access to the version library varies by version library. The Subversion client usually accesses the version library through the URL. Generally, the URL of the version library is in a standard format, just like a webpage. As shown below:

• Http://svn.example.com/svn/project
• Http://svn.example.com: 9834/Repos

Because subversion provides multiple methods for client-to-server interaction, the URL of the Subversion library is not limited to http: //, but also in other formats, as shown in the following table:

Table 1 subversion Database Access Method

Schema	Access Method
file:///	Direct repository access (on local disk)
http://	Access via WebDAV protocol to subversion-aware Apache server
https://	Samehttp://, But with SSL encryption
svn://	Access via custom protocol tosvnserveServer
svn+ssh://	Samesvn://, But through an SSH Tunnel

There are some notes about processing URLs using subversion. For example, the URL containing file: // access method (local version Library) must be one of the following two types:

• File: // var/SVN/Repos
• File: // localhost/var/SVN/Repos

4. working copy of subversion

A working copy of A Subversion is a common directory tree of your local system that contains a collection of files. You can edit and modify these files at will. The work copy is your private site. Before you display the commit, your work copy will not be incorporated into other people's modifications, and your modifications to the work copy will not be visible to others. Of course, subversion provides a series of operations for you to submit your modifications to the version library. If others have submitted the modifications, as mentioned in the previous article, you need to use the merge operation to write your modifications to the version library. In addition, work copies contain additional files created and maintained by subversion. For example, there is a. SVN subdirectory under each working copy Directory, which is the management directory of the working copy. Files in this directory help subversion to confirm which version files are not submitted for modification and which files are outdated.

5. the working mechanism of the working copy records two important information for each file in the working directory:

• Which revision is the working file based on?
• Timestamp record of the last update of the local copy from the version Library

A working file in subversion has the following four States: 1) the file is not modified, and the file is not modified, and the version library has not been modified since the last update The SVN commit command and the svn update command do not have to do anything.2) modify the file locally, and the file is not modified in the outdated working directory, and the version library has not been modified since the last update The SVN commit command writes the modified content, while the svn update command does not. 3) Not modified and out of date The file is not modified, but the file in the version library has been modified, and the local file is out of date. The SVN commit command does not do anything. SVN update adds the latest modification to the work copy. 4) Locally modified and outdated This file has been modified in the working directory, and the files in the version Library have been modified since the last update, that is, the local working copy is out of date. In this case, if there is a conflict, You need to perform the merge operation.
6. Working Copies interact with each other. A Subversion version library usually stores documents and source code of multiple projects. Each project exists in a sub-directory in the version library. As shown in, this is a subversion file system.
To get a working copy, you need to use the svn checkout command to export the subtree of the file system tree in the version library. For example, to export/calc, we will enter the following command:

$ svn checkout http://svn.example.com/repos/calcA    calc/MakefileA    calc/integer.cA    calc/button.cChecked out revision 56.$ ls -A calcMakefile  button.c integer.c .svn/$

To submit the changes to the version library, run the svn commit command. As shown below, the button. c file is changed and submitted to the version library. After that, if you have a working copy of The/calc checkout user, you will see your modifications.

$ svn commit button.c -m "Fixed a typo in button.c."Sending        button.cTransmitting file data .Committed revision 57.$

If there are multiple developers in the project, if other persons, Sally, work copies are checkout at the same time as you, then you are on the button. c changes cannot be made by Sally. To keep the working copy up-to-date, Sally can use the svn update command to update its working copy.

$ pwd/home/sally/calc$ ls -AMakefile button.c integer.c .svn/$ svn updateUpdating '.':U    button.cUpdated to revision 57.$

7. Mixed version work copies are often used in actual use. Assume that we have a project version from the version library checkout, as follows:

Calc/
Makefile: 4
Integer. C: 4
Button. C: 4

Modify the button. c file and use the commit command to submit the modification. The changes will become:

Calc/
Makefile: 4
Integer. C: 4
Button. C: 5

Assume that at this time, another collaborator Sally modified the File Integer. C and submitted to generate version 6. Then we use the svn update command to keep our working copy up-to-date. The working copy version is as follows:

Calc/
Makefile: 6
Integer. C: 6
Button. C: 6

Note that commit and update are separated in subversion.