Subversion (SVN), a new generation of version control systems that contribute to the open source community, has been used more and more widely. I have used CVS (the predecessor of Concurent Version SYSTEM,SVN) and Microsoft's VSS (Visual SourceSafe), in contrast, SVN has more powerful features and simpler operational features.
There are some articles on the web that describe the installation and use of SVN, but I still run into a few problems when I first configured it. Here, I follow my own ideas to help friends who first use SVN and have questions about questions.
1. SVN profile
Just say SVN is good, that SVN actually has what advantage. With a detailed description in the SVN manual, here are a few important aspects:
1) directory based version control
Traditional CVS or VSS is based on a single file version control, this actually does not meet the actual requirements, because in practical applications, we all want to follow the project or project management, for example, if we want to take out a historical point of the entire project file, then the File-based version control system is flawed, Can only be handled by a single file. And SVN can easily do this, you can arbitrarily remove any one file, any one of the historical version of the directory.
SVN also allows for additions, deletions, and duplication and renaming of files and directories, which are recorded in historical information to achieve true versioning capabilities.
2) Atomic Submission
Every operation in SVN is atomic, either all succeeds or all fails. Suppose you are submitting multiple files and if there is a conflict, no other modifications will be submitted.
3 Efficient branch (branching) and label (tagging) functions
First of all, the label function, in layman's terms, the label is a point-in-time snapshot (snapshot), we can make some important milestones in the project to create a label, so that you can easily take out these historical versions at any time. I think you'll have a question: Does SVN have the ability to take out any historical version of itself at random? Yes, the main purpose of the label is to give these specific historical versions a friendly name for ease of use and maintenance.
A branch is used to create multiple parallel lines of work, for example, when one of our projects needs to provide some special functionality to a particular user, you can create a branch for it that preserves most of the code and makes the entire project easier to maintain and manage.
SVN is the same for branching and labeling implementations, and employs a mechanism similar to unix/linux hard links (hard-link), which means that when we create a branch or label, SVN does not immediately create a copy of it, but instead creates a link, It is only when these files are modified that they actually produce a copy. This kind of "slow copy" method is a common optimization method, which can save space effectively.
What's the difference between a branch and a label? The difference is simply the meaning of the "contract moralize", which means that you will not modify it, and the branch means you will develop it.
4) Multiple Access Methods
SVN provides an abstract network access layer that can be accessed through different protocols. First, SVN provides a custom SVN protocol access that can be used with a URL like svn://host/repository. Again, SVN provides the ability to integrate with the Apache Web server so that we can access SVN in a http://host/repository way.
5 Support for binary files
Although CVS is also supported for binary files, but the implementation is not perfect, you may have encountered a text file with Chinese characters and is considered a binary file, SVN provides comprehensive support for binaries, so that non-text files can be as good as the text file version control.
6 clients that are integrated with the resource Manager under Windows: TORTOISESVN
SVN itself provides command-line operations only, and TORTOISESVN is a graphical interface developed by a third party that makes versioning easier to manage under Windows. However, because it is embedded in the resource manager, it can affect the speed of the system--and you can evaluate it yourself.
7 Platform-Independent
SVN adheres to the consistent advantage of open source software, which allows you to access the SVN server to each other, both on Windows and Linux platforms.
If you used to be a VSS user, here's a little bit of an idea that SVN has a different philosophy than VSS, where VSS puts version conflict control before the operation, and you have to perform checkout to lock and prevent others from being modified at the same time before you can manipulate a project. SVN provides the same lock functionality, but usually we just have to modify them independently without locking the project, and if there is a conflict at the time of submission, it means that SVN is putting conflict control behind the action and submitting it. You may think that VSS is more reasonable, but the reality is the opposite, because in our actual use, someone will checkout the whole project after forgetting the checkin, or did not choose recursive forgot to checkin the files in the subdirectory, so that other people can not modify, So had to artificially inform himself, very troublesome.
2. SVN Server Build
This section is written for administrators, and normal users can skip this section. I only use the installation of Windows as an example, Linux can be done in a similar way (some of the configuration parameters will be different, specific reference help manual).
1) Install SVN server
A. Download
SVN's official website is http://subversion.tigris.org/, and the latest version is 1.4.2. There are two types of binary installation packages under Windows, one is the setup file at the end of Setup, the other is a normal compressed package file, and the setup file automatically registers some information, such as environment variables and services, which can be implemented manually. When I was writing this article, the official website had only normal binaries, and it was estimated that the setup file would come out a little later. Special attention, download to read the attention of detail, see the matching software version number, to avoid problems.
The version I chose is Svn-win32-1.4.2.zip
B. Installation
Svn-win32-1.4.2.zip to the installation directory, I chose the C:/Program files/subversion, if it is a setup file, run the installation file directly. For a compressed package, we can add the bin path to the system environment variable for ease of operation. As you can see, there are several main files in the bin directory: svnadmin: Warehouse management tools, including creation, repair, and backup operations.
Svnlook: Warehouse view tools, including information, log and lock status, etc., will not cause changes in the warehouse.
SVNSERVE:SVN Service program that allows access to the warehouse through the SVN network protocol.
SVN:SVN client, which is used to access the warehouse for versioning of the project.
Svnversion: The client tool for viewing revision information for local copies.
C. Creating Warehouses (Repository)
SVN is a warehouse-version control unit, an SVN server can manage multiple warehouses, each with a separate revision number (REVISION), and any update in the warehouse will increment the revision number. You can choose to build one or more warehouses based on your needs, here, I create multiple warehouses as an example, assuming we put the warehouse in the D:/svn_repos directory, the following command will create a test warehouse under this directory: Svnadmin create D:/svn_repos /test If the creation succeeds, there will be one more Test directory under d:/svn_repos/.
2) Build Svnserve access mode
SVN and HTTP are two side-by-side access options, either of which you can choose or use.
A. Registration services
In order for the SVN service to run automatically after each boot, we need to register it as a service. Execute the following command in the console: sc create svnservice binpath= "/" C:/Program files/subversion/bin/svnserve.exe/"--service-r d:/svn_repos" start= Auto Note that the above commands are on one line. Sc.exe is a Windows 2000 system with a tool, 2000 No, can be copied from XP. Svnservice is the service name, the following parameter format has strict requirements, the equal sign preceded by no space and behind. The binpath itself has multiple arguments, so enclose it in quotes, and add a layer of quotation marks because there are spaces in the path. Both--service and-R are Svnserve.exe parameters that require it to run as a service, which indicates the root path of the warehouse (multiple warehouses are the parent directory of the warehouse).
SVN with the installation package will automatically register the service, at which point we may need to modify the-R parameter as follows: SC config svnservice binpath= "/" C:/Program files/subversion/bin/svnserve.exe/" --service-r D:/svn_repos "
B. Visits
After registering, start the service by running SC start Svnservice or the Service Manager (SERVICE.MSC).
Next, we can use the following command to test whether the system is working properly: SVN info svn://localhost/test
If the correct display of information about the warehouse, then it is done, otherwise please check the service parameters are configured correctly, for example, if the service parameter does not specify the correct-r value, you will get the following error: No repository found in ' svn://localhost/ Test '
If TORTOISESVN is installed, you can enter svn://localhost/test directly in the browser, which will pull up the TortoiseSVN repos-browser. You can then use TORTOISESVN to import the project for version management (see later).
C. Permission Configuration
All users can do anything before permission is configured, and in many cases they are not allowed. When you create a warehouse, several folders are generated in the warehouse directory, where the configuration information is stored in conf, including three files: Authz: access rights configuration
passwd: User name and password configuration
SVNSERVE.CONF: Basic configuration information
First configure the svnserve.conf, the inside of several configuration before the comments removed, the final content is as follows: [General]
Anon-access = Read
auth-access = Write
Password-db = passwd
Authz-db = Authz
The meaning files for these parameters are described in detail, where anon-access and auth-access are respectively access control for anonymous users and authenticated Users, password-db indicates the user password file path, authz-db indicates the permission profile path. There is also a parameter realm to indicate the authentication domain to which the warehouse belongs, by default each warehouse is in a different domain (each warehouse has a unique UUID), so we can not set it unless multiple warehouses need to share the same passwd configuration.
The configuration of the passwd file is simple, formatted as follows (the sign is preceded by the user name followed by the password): [Users]
Harry = 123
Sally = 123
Guest = 123
Authz You can create user groups and precisely configure access to a file or directory for a user or group of users, here's an example: [Groups]
harry_and_sally = harry,sally
[/]
* = R
[/project1]
* =
Harry = RW
Sally = R
[/project1/foo]
Sally =
[/project2]
@harry_and_sally = RW
Guest = R
The file content is actually very easy to understand, groups is used to define the user group, the following is the specific access control of the resource,/represents the warehouse root directory, * represents all users, the user group needs to precede the @ symbol, R is readable, W is writable, and the right side of the equal sign is empty Note For the directory structure, when a user accesses a resource, SVN will first see if there is access control directly against the resource, and if it is not found, it inherits access to the previous level of the directory, so it is recursive.
Again, when we have multiple warehouses, we find that the user accounts for these warehouses are the same in most cases, so we can put the passwd file in a public place and point the password-db configuration of all warehouses to that file. Accordingly, AUTHZ-DB can share a single file, although it is necessary to specify the warehouse to which the specific access control is configured, as follows: [/]
* = R
[Repos1:/project1]
* = R
Harry = RW
[Repos2:/project1]
* = R
Sally = RW The above configuration indicates that everyone has read access to the root directory of all warehouses, but only Harry has access to the Project1 in the warehouse repos1, and only Sally has read and write access to the Project1 in the warehouse Repos2.
3) Build HTTP access mode
SVN can implement Web access via Apache, but this is not necessary unless you have this requirement.
a) Download
Apache's official website is http://www.apache.org/, Be careful not to use the latest 2.2.x, but to choose 2.0.x, which is specifically stated on SVN's official website, which I didn't notice, which led to the inability to load the SVN module when Apache2.2 started, and "Perhaps this isn't" an Apache Module DSO "error."
The version I downloaded is Apache_2.0.59-win32-x86-no_ssl.msi
(b) Installation and registration
Execute Apache Setup. Since the 2.0 version is not automatically registered as a service, we need to handle it manually. Run Cmd.exe and enter the Bin folder under the Apache installation directory, and execute the following command: Apache-k install
More commands can be viewed via Apache help.
After registration, you can start the service through the Apache Monitor in the system tray. If the 80 port is not occupied, then the server should start normally, through http://127.0.0.1 will be able to see the Apache test page.
c) configuration
Apache is configured through the httpd.conf file in the Conf directory, for example, the default listening port is 80, search listen 80 in the file, and change 80 to the other ports you need. You must restart Apache to take effect when you have finished configuring. For more information on Apache configuration instructions, please refer to its Help manual or Google. The following website is the Chinese version of the Help manual.
To allow Apache to support SVN, such as adding some configuration items, a typical configuration is as follows:
# Load the Mod_dav module, which is supported by the WebDAV (Web-based Distributed Authoring and Versioning) protocol, which is brought by Apache
LoadModule Dav_module modules/mod_dav.so
# Load the MOD_DAV_SVN module, which communicates with MOD_DAV to enable Apache to support SVN, which is located in the SVN bin directory.
LoadModule dav_svn_module "D:/program files/subversion/bin/mod_dav_svn.so"
# load MOD_AUTHZ_SVN module for Rights Management
LoadModule authz_svn_module "D:/program files/subversion/bin/mod_authz_svn.so"
# Configure SVN access path and related parameters
<Location/svn/> # access to SVN server via http://HOST/svn/
DAV SVN # Required
Svnparentpath D:/svn_repos # Description All directories under D:/svn_repos are warehouses
Svnlistparentpath on # list all warehouses under D:/svn_repos in the Web page
AuthType Basic # User Name Password authentication method
AuthName "SVN REPOS" # certification name, for tips
AuthUserFile d:/svn_repos/users # User name password file
Authzsvnaccessfile D:/svn_repos/authz # Permission control file
Require Valid-user # Access to Web pages only through authentication
</Location>
# REDIRECT processing to redirect the HTTP://HOST/SVN address to http://HOST/svn/
Redirectmatch ^ (/SVN) $ $1/
Here are a few important places to illustrate:
I. Many articles on the Web refer to the direct copying of the mod_dav_svn.so and mod_authz_svn.so two files to the Apache modules directory, which I did when I did this in a Windows 2000 The Apache service cannot be started on the server for a long time. It became clear later that these module files were actually some dynamic link libraries that relied on several other DLL files in the SVN bin directory (you can change the suffix to a DLL and then view its dependencies through the VC band's depends), so if you don't set the environment variable, Then Apache will fail to load these modules, and of course it can copy all dependent files (mostly Libdb43.dll) over. In fact, we only need to refer to these modules through an absolute path so that SVN upgrades do not have to be copied again.
The access path to the URL is/svn/rather than/SVN, because the latter may be problematic, resulting in the following error message via HTTP://HOST/SVN access
Iii. Svnparentpath is used in cases where there are multiple warehouses, if only a single warehouse, you can specify the warehouse path directly with Svnpath.
IV. AUTHUSERFILE Specifies the username password file, but it is not the same file as the passwd file under the SVN warehouse mentioned earlier, AuthUserFile is the Apache authentication file format, the difference between the two is mainly the user name and the password of the separator is different, passwd is the equal sign, and the users here are colons, and I just used them as a file to make the client inaccessible (why does SVN not define the passwd format as AuthUserFile?). So that they can share a single file. If you want to encrypt the password, then the users file needs to be generated via the HTPASSWD tool that comes with Apache, and in fact we can also directly use plaintext.
V. Permission control file Authzsvnaccessfile is the same as the Authz in front of SVN, so it can be shared.
4 Other management functions
A. Backup
B. Repair
3. SVN client uses
This section is for client users, mainly introduces some common methods of operation.
1) Client Installation
The client can use the command line, or can use the TortoiseSVN graphical way, personally think or the latter more convenient.
TortoiseSVN from http://tortoisesvn.tigris.org/, note that the version should be consistent with the server. If it's a command-line approach, then download an SVN binary package from http://subversion.tigris.org/, not much here.
TortoiseSVN belongs to the graphical client software, in fact, the previous SVN installation package already contains the client program, but is the command line, you can choose whether or not to install. TortoiseSVN's official website is http://tortoisesvn.tigris.org/, too, and be careful to choose a version that is compatible with the SVN server.
The version I use here is Tortoisesvn-1.4.0.7501-win32-svn-1.4.0.msi
After installation, you will be prompted to restart the machine, in fact, can be used directly without a reboot, only after the restart will update the SVN file icon display. The following illustration is the right-click menu content for the SVN workspace:
2) Main operation
TortoiseSVN is simple to use and all operations are done through the right-click menu. Command content is also very intuitive, and there is a very detailed help manual, here only a brief introduction.
A to import the project (import)
The first thing to do is to organize the project (catalog) that needs to be versioned and remove unnecessary files, such as compiler-generated temporary files. Then right-click on the top-level folder, select TortoiseSVN-> Import ..., enter the SVN server path you want to store, and confirm. This imports the local project to the server.
Command line: SVN import [PATH] URL
(b) Check out the project (Checkout)
After the first successful import of the project, the local content is useless, we need to create a new workspace, download the controlled project file from the SVN server, execute "tortoisesvn-> Checkout ...", select or enter the URL of the project, confirm it, All future work should be done in this work area.
The default is to get the latest version of the Project (head), and if you want to get a historical version, specify the corresponding revision number (Revision).
Command line: SVN checkout url[@REV] ... [PATH]
c) Update and commit (update and commit)
Others have modified the project, we need to download the latest version from the server, which is implemented through the "SVN Update" right-click menu.
Command line: SVN update [PATH ...]
If you make a local change, you should update the changes to the server in time, which is achieved by "SVN Commit ...". A good habit is to specify the content of each submission to facilitate future verification.
Command line: SVN commit [PATH ...]
d) Add and delete files (add and delete)
If we want to add a new file or folder to a controlled project, just perform the "TortoiseSVN-> Add" action on the target. Note that this is only added locally, and a commit must be executed to commit to the server.
Command line: SVN add PATH ...
Similarly, you only need to perform the TORTOISESVN-> delete operation to delete a managed file or folder.
Command line: SVN delete Path/url ...
TORTOISESVN also provides a rename operation "TortoiseSVN-> Rename", which is actually a combination of additions and deletions.
e) Undo operation (Revert)
Sometimes we may make incorrect modifications or additions and deletions, and we can undo all local changes by using the "TortoiseSVN-> Revert" command, as long as no submissions are made.
Command line: SVN revert PATH ...
f) View information
SVN provides several ways to view the information, where show log is used to display logging information for each version change, Repo-brower is a warehouse browser, similar to a resource manager, and Revision graph lets us visually see the version changes in a graphical way, This is especially helpful for branching and label management.
3) Other operations
(a) Conflict resolution (resolved)
If we make a local change and someone else submits his changes to the server, we may have a conflict when we execute update (CONFLICT). Resolved's role is not to resolve conflicts, it does not do any merging, but ignores other people's modifications, allowing us to submit our version to the server.
Simply put, the revent is to undo the local modification, while the resolved is to keep the local modifications.
(b) Clear exception status (Cleanup)
If an exception occurs when a command is executed, such as when the server suddenly hangs, the local workspace is in an abnormal state that can be cleared by cleanup to keep the workspace unaffected.
c) lock (get Lock) and unlock (release lock)
Conflicts are caused by different developers modifying the same file at the same time, so in order to avoid this, we can force ourselves to lock the content we want to modify, so that others cannot submit their changes until we unlock them.
d) Branches and labels (branch/tag)
As explained at the outset of this article, the purpose of the branch is to create a parallel work line that is intended to hold a snapshot of a version of the project. The two are implemented in the same way, all through the Branch/tag command.
e) Exports (export)
To achieve versioning, SVN generates a hidden. SVN folder in each directory in the workspace, and we sometimes wish to get a clean one. The project structure of the SVN folder, such as the release of the software, allows you to use the export feature.
f) Redirect (relocate)
Sometimes, the IP address of the SVN server may change, and if this happens, each of our local workspaces will have to be downloaded again. No, just reconfigure the server address for the local workspace by relocate.
g) Patch management (patch)
Don't be fooled by Patch's name, it's not actually part of the SVN version management category. The so-called Patch here refers to those who do not write permission (Commit) of the person to make the changes, through the "TortoiseSVN-> create Patch" generated, and then they use e-mail and other ways to send Patch to the project administrator, the administrator to execute " TortoiseSVN-> Apply Patch "and confirm the content before submitting. This feature is mainly used for open source project management.
4. Frequently Asked Questions
1. What kind of directory organization structure should repository.