[SCM] source code management-SVN Server

ArticleDirectory

• Apache HTTP Server

I. SVN command line Introduction
1) command line SVN server and client download: http://www.collab.net/downloads/subversion/

2) set path: Set Path = "C: \ Program Files \ collabnet \ Subversion server"; % PATH %
3) command lines related to SVN server and client mainly include:

SVN and SVN subcommands include all client operations;

Svnadmin and svnadmin are used to manage SVN servers. The most important operation of server is to create the repository command svnadmin create;

Svnlook, svnlook, and its corresponding sub-commands are used for server management;

Svnserve is used to support SVN access to the server;

4) help: the help sub-command, such as SVN help checkout or svnadmin help create or svnlook help youngest
5) for more command instances, refer to book: Version Control with subversion-> Chapter 9. Subversion complete reference.

 

There are three access methods for SVN server: 1) file; 2) SVN or SVN + SSH; 3) HTTP or HTTPS.

 

Iii. SVN server creation process (SVN or SVN + SSH protocol access is supported, and svnserve is mainly used)

1 svnadmin

Create Repository: svnadmin create c: \ svnr

2 svnserve

1) Add users to file c: \ svnr \ conf \ passwd:

[Users]
Foo = bar

2) modify the conf file and open it in the file c: \ svnr \ conf \ svnserve. conf:

[General]
Anon-access = read
Auth-access = write
Password-DB = passwd

3) import the project and run svnserve:

Set svn_editor = notepad

SVN import c: \ test file: // C:/svnr

Svnserve-d -- log-file c: \ svnr \ log.txt-R c: \ svnr

3 SVN checkout

SVN checkout SVN: // ipforsvnr c: \ svnrwc

4 svnlook

Svnlook changed c: \ svnr

Svnlook log c: \ svnr

5. SVN can be combined with SSH permission authentication to ask: SVN list SVN + SSH: // host.example.com/repos/project

4. Create SVN server (File Access supported)

1. Create Repository: Create repository here using svnadmin or tortoisesvn

2 Access: SVN checkout file: // path/to/repos or remote machine access to SVN checkout file after sharing: // localhost/path/to/Repos

 

Five SVN server creation (support for HTTP or HTTPS, mainly using Apache server)

Apache's HTTP server is a "heavy" network server that can be used by subversion. Through a custom module, httpd can make the Subversion library visible before the client through the WebDAV/DeltaV protocol, the WebDAV/DeltaV protocol is an extension of HTTP 1.1 (see http://www.webdav.org/ for details ). This Protocol utilizes the ubiquitous HTTP protocol as the core of the Wan, and adds write capabilities-more specifically, versionized write-capabilities. As a result, a standardized and robust system is packaged as part of the Apache 2.0 software and supported by many operating systems and third-party products, and the network administrator does not need to open another custom port.

For details, refer to [SCM] source code management-SVN + Apache

 

Comparison

Svnserve Server

Why do you want to use it:

• Quick and easy to set.

• The network protocol is stateful and much faster than Apache (webDAV.

• You do not need to create a system account on the server.

• The password will not be transmitted over the network.

Why do you want to avoid it:

• The network protocol is not encrypted.

• Only one authentication method is available.

• Save the password in plaintext on this server.

• There are no types of logs or even errors.

Svnserve Use SSH Channel

Why do you want to use it:

• The network protocol is stateful and much faster than Apache (webDAV.

• You can use the existing SSH account and user base.

• All network transmission is encrypted.

Why do you want to avoid it:

• Only one authentication method is available.

• There are no types of logs or even errors.

• You must use the shared SSH key in the same system group.

• Incorrect use may cause file licensing problems.

Apache HTTP Server

Why do you want to use it:

• Subversion is allowed to use a large number of user authentication systems that have been integrated into Apache.

• You do not need to create a system account on the server.

• Complete Apache logs.

• Network transmission can be encrypted through SSL.

• HTTP (s) can usually cross the company firewall.

• Access the built-in version library through a web browser.

• The version library can be loaded as a network drive for transparent version control.

Why do you want to avoid it:

• It is much slower than svnserve because HTTP is a stateless protocol and requires more transmission.

• Initial settings may be complex

7 Suggestions
Subversion is recommended for small teams.SvnserveThis is the easiest way to set up and maintain the least. When your needs change, you can switch to complicated deployment methods.

Below are some common suggestions and tips, based on years of user support:

• If you try to build the simplest server for your team, installSvnserveIs the simplest and fastest method. Note that, in any case, if your entire deployment is in a LAN or VPN, version database data can be transmitted over the network without restrictions. If the version library is deployed on the internet, you want to make sure that the content of the version library is not sensitive (for exampleSource code.)

• If you want to integrate with an existing authentication system (LDAP, Active Directory, NTLM, X.509, etc.), you can only select an Apache server, if you absolutely need server-side logs (service logs or client activity), you also need the Apache server.

• If you have decided to use Apache orSvnserve, You should create a separateSVNYou also need to make sure that the version library directory belongsSVNUser. From the security point of view, this makes good use of the file system license of the operating system to protect the version database data. Only the Subversion service process can modify its content.

• If you have a base that relies heavily on an SSH account and your users already have an account on the server, it makes sense to create an SSH-based svnserve solution. Otherwise, we do not recommend this solution. NormallySvnserveOr users managed by Apache can access the version library securely, rather than using a full system account. If you want encrypted communication, you may still need to select this scheme, but we recommend the SSL Apache scheme.

• Do not be simply used by all usersFile ://Even if the version library has been visible to all users who share the network, this is not a good solution. In this way, all protection layers between the user and the version library are deleted: The user may accidentally (or intentionally) destroy the version database, which makes it difficult to take the version database offline during check or upgrade, in addition, this will cause a messy file license issue. Note that we warn you to use it.SVN + SSH ://Reason-From the security perspective, this is the same as accessing as a local userFile ://Yes. If the Administrator is not careful, the same problem may occur.

Eight references:

Http://svndoc.iusesvn.com/svnbook/1.4/svn.serverconfig.html

book: Version Control with subversion