Subversion configuration administrator guide in Windows

Author: rocksun Source: Subversion
 
Install subversion into service

The previous svnserve must depend on svnservice or other tools to become a Windows service. From subversion1.4, subversion itself is integrated with a Windows service tool.

1. Install svnservice

In Windows NT (including Windows XP, Windows 2000, and Windows 2003 Server), a tool for installing services is included, which is called "service control" and also supports SC .exe.

For example, if my subversion is installed in "D: \ subversion" and the version library is in "D: \ svnroot", I want the corresponding subversion service name to be svnservice, the command for installing the svn service can be written as follows:

SC create svnservice
Binpath = "D: \ subversion \ bin \ svnserve.exe -- service-r d: \ svnroot"
Displayname = "svnservice"
Depend = TCPIP

Note that the preceding command is divided into multiple lines, but it should be in one line during actual execution. In addition, the "-d" option, that is, the daemon mode, is used when svnserve is started previously. It cannot be used here, and the service cannot be started. Similarly, the "-I" and "-T" options cannot be used.

After the command is executed in the command line window, the service has not been started. You can continue to run "Net start svnservice" to start the service and then stop the service using "net stop svnservice.

There are two other points to be handled with caution. First, if the path contains spaces, you must use "\" to process the "signature number. If svnserve.exe is in" C: \ Program Files \ subversion, the command should be written as "binpath =" \ "C: \ Program Files \ subversion \ bin \ svnserve.exe \" (Content in ""). The entire command is as follows, the red part is the changed part:

SC create svnservice
Binpath = "\" D: \ Program Files \ subversion \ bin \ svnserve.exe \ "-- service-r d: \ svnroot"
Displayname = "svnservice"
Depend = TCPIP

SC also requires the option format. For example, "depend = TCPIP" cannot be written as "depend = TCPIP" or "depend = TCPIP ", that is, there must be spaces before "=.

2. delete a service

If there is a problem with the service installation, you may need to delete the service. To delete the previously added service, you only need to run "Net start svnservice". "svnservice" is the name we used when creating the service.

3. The configuration service is automatically started.

By default, the installed Service will not start with windows. To enable the svn service to start with windows, you need to modify the "SC create" command (Delete first ), add the "Start = auto" option:

SC create svnservice
Binpath = "D: \ subversion \ bin \ svnserve.exe -- service-r d: \ svnroot"
Displayname = "svnservice"
Depend = TCPIP
Start = auto

Of course, you can also use graphical tools to modify Service Attributes. You can run "services. msc" in "start-> Run..." And then modify the Service Attributes on the interface.

Subversion permission Control

1. authentication and authorization)

These two terms are often used together. Authentication means to identify the user. The most common method is to use the user name and password. authorization is to determine whether the user has certain operation permissions, the "authz-DB" file is provided in Subversion to implement path-based authorization, that is, to determine whether the user has the permission to operate the corresponding path. After subversion 1.3, both svnserve and Apache can use the "authz-DB" file.

2. configuration file under svnserve

Because this article uses svnserve as an example, we will first introduce the structure of the version library directory:

D: \ svnroot \ project1
├ ── Conf
├ ── Dav
Analytic DB
│ Bai── revprops
│ ─ ── Revs
│ Transactions
├ ── Hooks
─ ── Locks

Conf contains three files:

Authz
Passwd
Svnserve. conf

"Svnserve. conf" is the configuration file of this version library. When svnserve is used, this configuration file determines what authentication and authorization files are used:

Password-DB = passwd
Authz-DB = authz

The preceding configuration instructions use "svnserve. conf "is the same as passwd and authz in the directory. The password-DB specifies the user password file, and authz-DB is our authorization file, which is the file we will introduce in this article.

Note: When apache is used as the server, it does not reference the content of the "svnserve. conf" file, but Apache configuration.

3. svnserve-based version library file Layout

When using svnserve, the same authentication and authorization files should be used for management convenience, so the configuration files of all version libraries should be svnserve. conf points to the same password-DB and authz-DB files. The following is a multi-version library directory:

D: \ svnroot
├ ── Project1
│ ─ ── Conf
│ ├ ── Dav
│ ─ ── DB
│ ─-Revprops
│ ── Revs
│ Transactions
│ ─ ── Hooks
│ ─ ── Locks
└ ── Project2
├ ── Conf
├ ── Dav
Analytic DB
│ Bai── revprops
│ ─ ── Revs
│ Transactions
├ ── Hooks
─ ── Locks

D: \ svnroot has two directories: project1 and project2, both of which have created version libraries. Therefore, we modify the svnserve under each conf directory. conf to point to the same password-DB and authz-DB files.

Password-DB =... \ passwd

Authz-DB =... \. \ authz. D: \ svnroot \ passwd and D: \ svnroot \ authz control svnserve Access to All version libraries. In addition, to disable anonymous access in subsequent operations, remove the "#" before "Anon-access = none" to ensure that only authenticated users can access the service.

Note: The value of "Realm" of svnserve should also be noted. In the preceding settings, ensure that all vertices use the same realm value, the password cache for version libraries can be shared among multiple version libraries. For more details, see client credential cache.

4. Test user and group description

The version library prohibits access by any anonymous users and is only valid for authenticated users.

Root: the configuration administrator has full management permissions on the version library.

P1_admin1: Administrator of project1, with full permissions on project1.
P1_d1: the developer of project1 has full permissions on the trunk of project1, but has no permissions on the/trunk/Admin directory.
P1_t1: The tester of project1 has full read permission on the trunk of project1, but has no permission on the/trunk/Admin directory.

P2_admin1: the Administrator of project2, who has full permissions on project2.
P2_d1: the developer of project2 has full permissions on the trunk of project2, but has no permissions on the/trunk/Admin directory.
P2_t1: The tester of project2 has full read permission on the trunk of project2, but has no permission on the/trunk/Admin directory.

Users in the corresponding group and group:

P1_group_a: p1_admin1
P1_group_d: p1_d1
P1_group_t: p1_t1
P2_group_a: p2_admin1
P2_group_d: p2_d1
P2_group_t: p2_t1

5. Modify the D: \ svnroot \ passwd file.

As mentioned above, the user and password file should be in D: \ svnroot \ passwd, so we set permissions for each user. The file content is as follows:

[Users]
P1_admin1 = p1_admin1
P1_d1 = p1_d1
P1_t1 = p1_t1

P2_admin1 = p2_admin1
P2_d1 = p2_d1

P2_t1 = p2_t1 in order to facilitate verification, all passwords are the same as the user name. If you are using another authentication method, this step may be different, but the user name should be the same.

6. Configure authorization and modify D: \ svnroot \ authz.

[Groups]
# Define group information

P1_group_a = p1_admin1
P1_group_d = p1_d1
P1_group_t = p1_t1

P2_group_a = p2_admin1
P2_group_d = p2_d1
P2_group_t = p2_t1

[/]
# Specify that all version libraries are read-only by default and can be read and written by root.
* = R
Root = RW

[Project1:/]
# Specify permissions for the root directory of the version library project1
@ P1_group_a = RW
@ P1_group_d = RW
@ P1_group_t = r

[Project1:/trunk/admin]
# Specify the permission for the/trunk/admin root directory of the version library project1,
# P1_group_a: read and write, p1_group_d and p1_group_t do not have any permissions.
@ P1_group_a = RW
@ P1_group_d =
@ P1_group_t =

[Project2:/]
# Specify permissions for the Project 2 root directory of the version Library
@ P2_group_a = RW
@ P2_group_d = RW
@ P2_group_t = r

[Project2:/trunk/admin]
# Specify the permission for the/trunk/admin root directory of the version library project1
@ P2_group_a = RW
@ P2_group_d =
@ P2_group_t =
 

After the above settings, you will find some interesting things. When the user "p1_d1" is used to check the trunk of project1, the directory is empty, as if the Admin directory does not exist at all. When the p1_d1 user browses the version library, the Admin directory is displayed, however, the content cannot be seen.

About the Chinese directory, there is no problem, just pay attention to the authz file into UTF-8 format, in my WINXP ultraedit display file format for U8-DOS, the specific approach is to use ultraedit to open the authz file, then select File-> convert-> ASCII to UTF-8, and then save.

This is even more complex. In actual work, you must first plan the permissions and grant only the minimum permissions to the users to implement the most complex permission control with the minimum configuration.

Subversion backup

The most important thing about version control is to ensure data security,ProgramFaults cause irreparable errors to the version library. Therefore, a complete backup policy must be developed. In subversion, we have three backup methods: Full backup, Incremental backup, and synchronization version library.
1. Full backup

The most common and simple backup is to directly use the copy command to copy the version library directory to the backup directory. However, this is not a safe method, because if the version library changes during the copy process, the backup results will be inaccurate and the backup function will be lost, therefore, subversion provides the "svnadmin hotcopy" command to prevent this problem.

Do you still remember our version library directory?

D: \ svnroot
├ ── Project1
│ ─ ── Conf
│ ├ ── Dav
│ ─ ── DB
│ ─-Revprops
│ ── Revs
│ Transactions
│ ─ ── Hooks
│ ─ ── Locks
└ ── Project2
├ ── Conf
├ ── Dav
Analytic DB
│ Bai── revprops
│ ─ ── Revs
│ Transactions
├ ── Hooks
─ ── Locks
 

To back up project1 to the d: \ svnrootbak directory, run:

Svnadmin hotcopy D: \ svnroot \ project1 D: \ svnrootbak \ project1

However, as the configuration administrator, we must try to optimize this process. If there are many version libraries in this directory, We need to write such a statement backup for each version database, for this reason, I wrote the following script to back up all the version libraries in a directory. We created two files under D: \ svnroot, simplebackup. BAT:

@ ECHO is backing up version library % 1 ......
@ % Svn_home % \ bin \ svnadmin hotcopy % 1% backup_directory % \ % 2
@ Echo version library % 1 successfully backed up to % 2!

This file is only for "svnadmin hotcopy" packaging, followed by backup. BAT:

Echo off

Rem subversion installation directory
Set svn_home = "D: \ subversion"

Parent directory of all REM versions
Set svn_root = D: \ svnroot

Rem Backup Directory
Set backup_svn_root = D: \ svnrootbak

Set backup_directory = % backup_svn_root % \ % Date :~ 0, 10%
If exist % backup_directory % goto checkback
Echo create Backup Directory % backup_directory %> % svn_root %/backup. Log

Mkdir % backup_directory %

Rem verifies whether the directory is a version library. If yes, the name backup is taken out.
For/R % svn_root % I in (.) Do @ if exist "% I \ conf \ svnserve. conf" % svn_root % \ simplebackup. Bat "% ~ Fi "% ~ Ni
Goto end

: Checkback
Echo Backup Directory % backup_directory % already exists. Please clear it.
Goto end

: End

You only need to modify the three paths starting with backup. BAT and copy the two scripts to "svn_root. Based on the above configuration, you only need to run backup. bat, you can back up the version Libraries under "svn_root" to "backup_svn_root" and store them in the directory of the backup day, for example, "d: \ svnrootbak \ 2006-10-22 ".

Although this part of work is very simple, someone must perform this operation on a regular basis (for example, every Monday morning). To avoid forgetting, we can add this operation to the system's at task, for example, the above environment. To install the at task, we run:

At/every: m d: \ svnroot \ backup. bat will execute this backup process at every Monday. Of course, the backup is not safe on the local machine. You may need to upload the backup to another machine. You must implement the backup on your own.

2. Incremental Backup

Full backup is simple but costly. When the version library is very large, it is unrealistic and unnecessary to perform full backup, but what should I do if there is a problem between the backup of the version library? Here we use Incremental backup.

Incremental backup is usually used in combination with full backup, just like the archive log of the Oracle database, which records the changes submitted every time the Subversion is changed, and then returns to the latest available status when recovery is required. In this example, we use the svnadmin dump command to perform Incremental backup by using the following methods:

Svnadmin dump project1 -- Revision 15 -- incremental> dumpfile2

The preceding command implements Incremental backup of revision 15. The output file dumpfile2 only saves the modified content of revision 15.

To record the results submitted each time, we need to use a subversion feature-hook to see our project1 directory:

├ ── Project1
│ ─ ── Conf
│ ├ ── Dav
│ ─ ── DB
│ ─-Revprops
│ ── Revs
│ Transactions
│ ─ ── Hooks
│ ─ ── Locks

The hooks directory contains the hook script. Here we only use the post-commit hook. This hook will be executed after each submission. In order to implement our backup function, we create a file post-commit.bat Under hooks with the following content:

Echo off
Set svn_home = "C: \ Program Files \ subversion"
Set svn_root = D: \ svnroot
Set unix_svn_root = D:/svnroot
Set delta_backup_svn_root = D: \ svnrootbak \ Delta
SET LOG_FILE = % 1 \ backup. Log
Echo backup revision % 2> % LOG_FILE %
For/R % svn_root % I in (.) do if D:/svnroot/% ~ Ni = % 1% svn_root % \ % ~ Ni \ hooks \ deltabackup. Bat % ~ Ni % 2
Goto end
: End

Through this script, the version library under D: \ svnroot can be automatically incrementally backed up to D: \ svnrootbak \ Delta when it is submitted (this directory is determined to exist), where the deltabackup is used. BAT can be stored anywhere, but it is packaged with the svnadmin dump of the script. The content is as follows:

@ ECHO is backing up version library % 2 ......
% Svn_home % \ bin \ svnadmin dump % svn_root % \ % 1 -- incremental -- Revision % 2> % delta_backup_svn_root % \ % 1. Dump
@ Echo version library % 2 successfully backed up to % 3!

The above two scripts can be directly copied to the hooks directory of project2, and automatic backup of project2 can be achieved without modification.

The above operations are OK. Now we need to combine full backup and Incremental backup, that is, to clear the Incremental backup after full backup, to save only the results after full backup.

If a version database fault occurs, we need to restore the version database. This is to use the svnadmin load command, at the same time, you also need the last full backup, for example, to make the last full backup backuprepo, and the subsequent Incremental Backup dumpfile:

Svnadmin load backuprepo <dumpfile

Finally, you can download svnroot.rar, decompress it to D: \, and modify the svn_home of several BAT files.

3. Version library Synchronization

Subversion 1.4 adds a synchronization mechanism to synchronize a version library with another version Library (but it seems to be only one-way). We can implement backup or image of the version library.

3.1. initialize the target database

Svnsync init SVN: // localhost/project2 SVN: // localhost/project1
Project2 is the target version library, while project1 is the source version library. The target version library must be empty and must allow modifications to the Revision property, that is, adding a file pre-revprop-change.bat to the hooks directory of the target version library with a blank content.

3.2. Synchronize project2 to project1

Svnsync sync SVN: // localhost/project2
At this time, you can update a copy of project2 to find all the content of project1. If project1 is submitted again, the latest changes cannot be seen in the version library of project2. You need to run the sync operation again to synchronize the latest changes. Note that the target version library can only be read-only. If the target version library is changed, the synchronization will not continue.

3.3. Modify synchronization history attributes

Because synchronization does not update changes to historical attributes, svnsync also has a sub-command copy-revprops to synchronize attributes of a specific version.

3.4. Automatic hook Synchronization

To synchronize data at each commit, you need to add the post-commit script to the source database. The content is as follows:

Echo off
Set svn_home = "D: \ subversion"
% Svn_home % \ bin \ svnsync sync -- non-interactive SVN: // localhost/project2

Store the above content as a post-commit.bat, and then put it under the hooks directory under the version library project1, so that each submission of project1 will cause synchronization of project2.