创建一个 Subversion 版本库出乎寻常的简单。 Subversion提供的svnadmin 工具,有一个执行这个功能的子命令。要建立一个新的版本库,只需要运行:
$ svnadmin create /path/to/repos
在 Subversion 1.2中,版本库默认使用FSFS后端存储方式来创建(见“版本库数据存储”一节)。不管怎样,存储类型可以使用--fs-type
参数明确说明:
$ svnadmin create --fs-type fsfs /path/to/repos
$ svnadmin create --fs-type bdb /path/to/other/repos
不要在网络共享上创建Berkeley DB版本库—它不能存在于诸如NFS, AFS或Windows SMB的远程文件系统中,Berkeley数据要求底层文件系统实现严格的POSIX锁定语义,几乎没有任何网络文件系统提供这些特性,假如你在网络共享上使用BerkeleyDB,结果是不可预知的——许多错误可能会立刻发现,也有可能在几个月之后才能发现
假如你需要多台计算机来访问,你需要在网络共享上创建FSFS版本库,而不是Berkeley DB的版本库。或者更好的办法,你建立一个真正的服务进程(例如Apache或svnserve),把版本库放在服务器能访问到的本地文件系统中,以便能通过网络访问。详情请参看linkend="svn.serverconfig"/>。
你可能已经注意到了,svnadmin命令的路径参数只是一个普通的文件系统路径,而不是一个svn客户端程序访问版本库时使用的URL。svnadmin和svnlook都被认为是服务器端工具—它们在版本库所在的机器上使用,用来检查或修改版本库,不能通过网络来执行任务。一个Subversion的新手通常会犯的错误,就是试图将URL(甚至“本地”file:
路径)传给这两个程序。
所以,当你运行svnadmin create命令后,就会在运行目录创建一个崭新的Subversion版本库,让我们看一下在这个目录创建中创建了什么。
$ ls repos
conf/ dav/ db/ format hooks/ locks/ README.txt
除了README.txt
和format
文件,版本库目录就是一些子目录了。就像Subversion其它部分的设计一样,模块化是一个很重要的原则,而且层次化的组织要比杂乱无章好。下面是对新的版本库目录中各个项目的简要介绍:
一个存储版本库配置文件的目录。
提供给Apache和mod_dav_svn的目录,让它们存储自己的数据。
你所有的受版本控制数据的所在之处。这个目录或者是个Berkeley DB环境(满是数据表和其他东西),或者是一个包含修订版本文件的FSFS环境。
包含了用来表示版本库布局版本号的整数。
一个存储钩子脚本模版的目录(还有钩子脚本本身, 如果你安装了的话)。
一个存储Subversion版本库锁定数据的目录,被用来追踪对版本库的访问。
这个文件只是用来告诉它的阅读者,他现在看的是 Subversion 的版本库。
一般来说,你不需要手动干预版本库。svnadmin工具应该足以用来处理对版本库的任何修改,或者你也可以使用第三方工具(比如Berkeley DB的工具包)来调整部分版本库。不过还是会有些例外情况,我们会在这里提到。
$ ls repos/hooks/
post-commit.tmpl post-unlock.tmpl pre-revprop-change.tmpl
post-lock.tmpl pre-commit.tmpl pre-unlock.tmpl
post-revprop-change.tmpl pre-lock.tmpl start-commit.tmpl
start-commit
pre-commit
Subversion的分发版本包括了一些访问控制脚本(在Subversion源文件目录树的tools/hook-scripts
目录),可以用来被pre-commit调用来实现精密的写访问控制。另一个选择是使用Apache的httpd模块mod_authz_svn,可以对单个目录进行读写访问控制(见“每目录访问控制”一节)。在未来的Subversion版本中,我们计划直接在文件系统中实现访问控制列表(ACLs)。
post-commit
它在事务完成后运行,创建一个新的修订版本。大多数人用这个钩子来发送关于提交的描述性电子邮件,或者作为版本库的备份。版本库传给程序两个参数:到版本库的路径和被创建的新的修订版本号。退出程序会被忽略。
Subversion分发版本中包括mailer.py和commit-email.pl脚本(存于Subversion源代码树中的tools/hook-scripts/
目录中)可以用来发送描述给定提交的email(并且或只是追加到一个日志文件),这个mail包含变化的路径清单,提交的日志信息、日期和作者以及修改文件的GNU区别样式输出。
Subversion提供的另一个有用的工具是hot-backup.py脚本(在Subversion源代码树中的tools/backup/目录中)。这个脚本可以为Subversion版本库进行热备份(Berkeley DB数据库后端支持的一种特性),可以制作版本库每次提交的快照作为归档和紧急情况的备份。
pre-revprop-change
因为Subversion的修订版本属性不是版本化的,对这类属性的修改(例如提交日志属性svn:log
)将会永久覆盖以前的属性值。因为数据在此可能丢失,所以Subversion提供了这种钩子(及与之对应的post-revprop-change
),因此版本库管理员可用一些外部方法记录变化。作为对丢失未版本化属性数据的防范,Subversion客户端不能远程修改修订版本属性,除非为你的版本库实现这个钩子。
这个钩子在对版本库进行这种修改时才会运行,版本库给钩子传递四个参数:到版本库的路径,要修改属性的修订版本,经过认证的用户名和属性自身的名字。
post-revprop-change
我们在前面提到过,这个钩子与pre-revprop-change
对应。事实上,因为多疑的原因,只有存在pre-revprop-change
时这个脚本才会执行。当这两个钩子都存在时,post-revprop-change
在修订版本属性被改变之后运行,通常用来发送包含新属性的email。版本库传递四个参数给该钩子:到版本库的路径,属性存在的修订版本,经过校验的产生变化的用户名,和属性自身的名字。
Subversion分发版本中包含propchange-email.pl脚本(在Subversion源代码树中的tools/hook-scripts/
目录中),可以用来发送修订版本属性修改细节的email(并且或只是追加到一个日志文件)。这个email包含修订版本和发生变化的属性名,作出修改的用户和新属性值。
pre-lock
这个钩子会在每次有人尝试锁定文件时执行,可以防止完全的锁定,或者用来制定控制哪些用户可以锁定特定路径的复杂策略,如果钩子发现已存在的钩子,也可以决定是否“窃取”这个钩子。版本库传递三个参数到钩子:到版本库的路径、锁定的路径和企图执行锁定的用户。如果程序返回非零值,锁定动作会退出,并且所有的标准输出返回到客户端。
post-lock
这个钩子在一个路径被锁定后执行,锁定的路径传递给钩子的标准输入,这个钩子也接受两个参数:到版本库的路径和企图执行锁定的用户。可以用这个钩子发送通知邮件来记录这种锁定事件,因为锁定已经发生,输出会被钩子忽略。
pre-unlock
这个钩子在某人企图删除一个文件上的钩子时发生,可以用来制定哪些用户可以解除文件锁定的策略。制定破坏锁定的策略非常重要,如果一个用户A锁定了一个文件,允许用户B打开这个锁?如果这个锁已经一周了呢?这种事情可以通过钩子决定并执行。版本库传递三个参数到钩子:到版本库的路径、将要解锁的路径和企图解锁的用户。如果程序返回非零值,解锁操作退出并会将标准错误传输到客户端。
post-unlock
钩子在一个路径被解锁后执行,被解锁的路径会传递到钩子的标准输入,钩子也会得到两个参数:到版本库的路径和删除锁定的用户。可以用钩子发送记录这些事件的邮件。因为删除已经发生,钩子的输出被忽略。
不要尝试用钩子脚本修改事务。一个常见的例子就是在提交时自动设置svn:eol-style
或svn:mime-type
这类属性。这看起来是个好主意,但它会引起问题。主要的问题是客户并不知道由钩子脚本进行的修改,同时没有办法通告客户它的数据是过时的,这种矛盾会导致出人意料和不能预测的行为。
作为尝试修改事务的替代,我们通过检查pre-commit
钩子的事务,在不满足要求时拒绝提交。
Subversion会试图以当前访问版本库的用户身份执行钩子。通常,对版本库的访问总是通过ApacheHTTP服务器和mod_dav_svn进行,因此,执行钩子的用户就是运行Apache的用户。钩子本身需要具有操作系统级的访问许可,用户可以运行它。另外,其它被钩子直接或间接使用的文件或程序(包括Subversion版本库本身)也要被同一个用户访问。换句话说,要注意潜在的访问控制问题,它可能会让你的钩子无法按照你的目的顺利执行。
联系客服