[SCM]源码管理 - SVN Server

一 SVN命令行简介
1）命令行方式的SVN Server和Client下载： http://www.collab.net/downloads/subversion/

2）设置path路径：set path="C:\Program Files\CollabNet\Subversion Server";%path%
3）svn 的server 和 client相关的命令行主要包含：

svn，svn子命令包含了所有的client操作；

svnadmin，svnadmin用来管理SVN Server，其中Server最主要的一个操作就是创建repository命令svnadmin create；

svnlook，svnlook及其相对应的子命令用来server管理；

svnserve，用来对server提供svn访问的支持；

4）帮助：命令 help 子命令，例如svn help checkout 或svnadmin help create 或svnlook help youngest
5）更多命令实例参考 book：Version Control with Subversion-> Chapter 9. Subversion Complete Reference

二 SVN server的访问方式有三种：1）file；2）svn 或 svn+ssh；3）http 或 https。

三 SVN server 创建过程（支持svn或svn+ssh协议访问，主要使用svnserve）

1 svnadmin

创建repository ：svnadmin create c:\svnR

2 svnserve

1）增加users，在文件C:\svnR\conf\passwd中增加:

[users]
foo = bar

2) 修改conf，在文件C:\svnR\conf\svnserve.conf中打开：

[general]
anon-access = read
auth-access = write
password-db = passwd

3）导入project然后运行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可以和ssh的权限认证结合起来，让问如：svn list svn+ssh://host.example.com/repos/project

四 svn server创建（支持file访问）

1 创建Repository ：使用svnadmin或TortoiseSVN的create repository here

2 访问：svn checkout file:///path/to/repos 或共享后远程机器访问 svn checkout file://localhost/path/to/repos

五 svn server创建(支持http或https，主要使用apache服务器)

Apache 的HTTP服务器是一个Subversion可以利用的“重型”网络服务器，通过一个自定义模块，httpd可以让Subversion版本库通过 WebDAV/DeltaV协议在客户端前可见，WebDAV/DeltaV协议是HTTP 1.1的扩展（见http://www.webdav.org/来查看详细信息）。这个协议利用了无处不在的HTTP协议是广域网的核心这一点，添加了写能力—更明确一点，版本化的写—能力。结果就是这样一个标准化的健壮的系统，作为Apache 2.0软件的一部分打包，被许多操作系统和第三方产品支持，网络管理员也不需要打开另一个自定义端口。

详细参考： [SCM]源码管理 - SVN + Apache

六比较

svnserve服务器

为什么你会希望使用它：

设置快速简单。
网络协议是有状态的，比apache（WebDAV）快很多。
不需要在服务器创建系统帐号。
不会在网络传输密码。

为什么你会希望避免它：

网络协议没有加密。
只有一个认证方法选择。
在这个服务器上明文保存密码。
没有任何类型的日志，甚至是错误。

svnserve使用SSH通道

为什么你会希望使用它：

网络协议是有状态的，比apache（WebDAV）快很多。
你可以利用现有的ssh帐号和用户基础。
所有网络传输是加密的。

为什么你会希望避免它：

只有一个认证方法选择。
没有任何类型的日志，甚至是错误。
需要用户在同一个系统组，使用共享ssh密钥。
如果使用不正确，会导致文件许可问题。

Apache 的 HTTP 服务器

为什么你会希望使用它：

允许Subversion使用大量已经集成到Apache的用户认证系统。
不需要在服务器创建系统帐号。
完全的Apache日志。
网络传输可以通过SSL加密。
HTTP(S) 通常可以穿越公司防火墙。
通过web浏览器访问内置的版本库浏览。
版本库可以作为网络驱动器加载，实现透明的版本控制。

为什么你会希望避免它：

比svnserve慢很多，因为HTTP是无状态的协议，需要更多的传递。
初始设置可能复杂

七建议
通常，推荐开始使用Subversion的小团队使用svnserve；这是设置最简单，维护最少的方法，而当你的需求改变时，你可以转换到复杂的部署方式。

下面是一些常见的建议和小技巧，基于多年对用户的支持：

如果你尝试为你的团队建立最简单的服务器，安装svnserve是最简单的，最快速的方法。注意，无论如何，如果你的整个部署都是在局域网或者VPN中，版本库数据可以在网络上没有限制的传递。如果版本库部署在internet，你会希望确定版本库的内容不是敏感的（例如只包含开源代码。）
如果你希望与现有的认证系统（LDAP、Active Directory、NTLM、X.509等）集成，你你只能选择Apache服务器，同样的，如果你绝对需要服务器端的日志（服务日志或客户端活动），也需要Apache服务器。
如果你已经决定使用Apache或svnserve，应该单独创建一个运行服务器进程的svn用户，也需要确定版本库目录属于svn用户。从安全的角度，这样很好的利用了操作系统的文件系统许可保护了版本库数据，只有Subversion服务进程可以修改其内容。
如果你有一个严重依赖于SSH帐号的基础，而且你的用户已经在服务器上有了帐号，那建立一个通过ssh的svnserve方案就非常有意义，否则，我们不会建议这种方案。通常还是通过svnserve或Apache管理的用户访问版本库比较安全，而不是使用完全的系统帐户。如果你很希望加密的通讯，那可能还是需要选择这个方案，但我们更加推荐SSL的Apache方案。
不要被简单的让所有用户使用file://的 URL访问版本库的方案诱惑，即使，版本库版本库已经对网络共享的所有用户可见，这也不是一个好方案。这样删除了用户和版本库之间的所有保护层：用户可能会偶然（或有意的）毁坏版本库数据库，这样也很难在检查或升级时将版本库脱机，而且这样会造成曾混乱的文件许可问题，注意那就是我们警告使用svn+ssh://的原因—从安全角度讲，这样与作为本地用户访问file://是一样的，如果管理员不小心，会造成同样的问题。

八参考：

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

book：Version Control with Subversion