svn常见问题

svn常见问题

svn 2011-04-18 00:09:59 阅读123 评论0   字号：大中小 订阅

1. SVN 疑难解答

 

1.1. 刚刚在本目录下执行一个提交，而后执行 "svn log"，怎么看不到最新的提交？

“明明是刚在本目录下执行了一次提交，为何 "svn log"，看不到呢？”

若是您是使用分布式版本控制工具（如 git, hg, bzr），或者使用 CVS 的用户，会对此现象感到很是奇怪。

缘由分析:

问题的实质是 SVN 的混杂版本号。

 执行 "svn status -v" 命令能够看到当前目录处于混杂版本状态。

不一样的版本控制工具使用不一样的方法记录本地工做目录下文件的状态

分布式版本控制工具在工做区的最顶级目录包含惟一一个控制目录（如 .git, .hg, .bzr ── 实际为版本库自己）

Subversion在每个工做目录下都包含一个名为 .svn 的控制目录，记录着每个文件以及当前目录的版本号

相比之下，Subversion虽然采用了全局版本号，但本地记录目录和文件的版本散布在各个 .svn 目录中

当刚刚完成一次提交，仅仅该次提交涉及的文件在 .svn 控制目录中记录的版本号是最新的，其它的文件包括目录自己的版本号仍是旧的。

“难道提交不该该自动更新全部文件和目录状态么？”

但这是不合理的，可能因为他人的修改破坏当前工做区，所以只有主动执行 "svn update" 命令，才进行更新。

解决办法:

在目录下执行一次 "svn update"，以后再执行 "svn log"，就在日志中可以看到刚刚的提交。或者使用命令 "svn log -rHEAD:1" 也能够看到最新提交实践出如今 log 中。

1.2. 修改目录属性提交报错：“目录 “XXX” 已通过时”！而这个目录当前只有我一我的在改动，没有其余人修改。

问题重现:

修改当前目录下的文件，以后提交。提交完毕后，不要执行 "svn update"，直接修改当前目录的属性，当再次提交时报错：

正在发送 XXX svn: 提交失败(细节以下): svn: 目录 “/trunk/XXX” 已通过时

缘由分析:

问题的实质仍然是 SVN 的混杂版本号。  执行 "svn status -v" 命令能够看到当前目录处于混杂版本状态。

前一次的提交，并未更新当前目录的版本号，从而致使当前目录的版本号不是最新。当修改目录属性并提交时，引起 “目录已通过时” 的错误。

解决方案：

在当前目录下执行 "svn update"，以后再执行提交。

1.3. 为何提交后，在日志中看不到提交者 ID？提交者为空！

若是在提交日志中的提交者为空，说明 Subversion 配置了容许匿名用户提交，在正式的部署中，是不该该出现的。

解决方案：

登陆 Subversion 管理后台，如地址： http://dev.moon.ossxp.com/pysvnmanager

检查权限设置

删除容许匿名用户登陆的策略

确认在缺省版本库([/]) 的根模组（/）中存在一条 “*=r” 或者 “*=” 的策略。

1.4. 如何更改个人口令？

进入单点登陆页面，登陆后，访问帐号管理界面，修改口令。如图：

1.5. 忘记口令怎么办？

进入单点登陆页面，点击页面中的“忘记口令”的连接。如图：

1.6. Subversion 错误信息一览表

 注意：

不一样的客户端（命令行，TortoiseSVN, AnkhSVN, Subclipse等）的出错信息可能稍有不一样。

下面表格中的出错信息以 http://svn.moon.ossxp.com/svn/test 版本库作示例，仅供参考。

编号	出错信息	问题剖析	解决方案
1.	svn: Server sent unexpected return value (500 Internal Server Error) in response to OPTIONS request for 'http://svn.moon.ossxp.com/svn/test'	错误的用户名	检查登陆的用户名是否输入错误
	svn: 服务器发送了意外的返回值(500 Internal Server Error)，在响应 “OPTIONS” 的请求 “http://svn.moon.ossxp.com/svn/test” 中
2.	svn: OPTIONS of 'http://svn.moon.ossxp.com/svn/test': authorization failed: Could not authenticate to server: rejected Basic challenge (http://svn.moon.ossxp.com)	错误的口令	用正确的用户名/口令登陆
	svn: 方法 OPTIONS 失败于 “http://svn.moon.ossxp.com/svn/test”: 认证失败: Could not authenticate to server: rejected Basic challenge (http://svn.moon.ossxp.com)
3.	svn: Server sent unexpected return value (403 Forbidden) in response to OPTIONS request for 'http://svn.moon.ossxp.com/svn/test'	用户无权限	联系管理员，为用户分配权限
	svn: 服务器发送了意外的返回值(403 Forbidden)，在响应 “OPTIONS” 的请求 “http://svn.moon.ossxp.com/svn/test” 中
4.	svn: OPTIONS of 'http://www.moon.ossxp.com/svn/test': 200 OK (http://www.moon.ossxp.com)	服务器地址错误，是普通Web页面，不支持SVN的 WebDAV 协议	确认输入正确的 SVN 服务地址。能够在浏览器中输入该地址进行确认
	svn: 方法 OPTIONS 失败于 “http://www.moon.ossxp.com/svn/test”: 200 OK (http://www.moon.ossxp.com)
5.	The version of your subversion (client) is below 1.5.0, upgrade to 1.5.0 or above. SVN below 1.5.0 can not handle mergeinfo properly. It can mess up our automated merge tracking!	是因为客户端的软件版本低于1.5.0形成的。服务器端对客户端软件版本进行了限制，以避免对合并跟踪破坏。	升级本地的Subversion客户端软件到1.5.0或以上版本。
6.	svn: This client is too old to work with working copy '.'. You need to get a newer Subversion client, or to downgrade this working copy. See http://subversion.tigris.org/faq.html#working-copy-format-change for details.	安装了多个版本的SVN客户端(TSVN,Subclipse,...)，且各个客户端的版本不一致。高版本的SVN客户端会自动更新本地工做目录中的 .svn 目录下的文件格式，致使旧版本的SVN客户端不能继续访问该本地工做目录	将本机安装的全部的SVN客户端都更新到同一个大版本，以免本地工做目录的格式不一致
	svn: 此客户端对于工做副本 “.” 太旧。你须要取得更新的 Subversion 客户端，或者降级工做副本。 参见 http://subversion.tigris.org/faq.html#working-copy-format-change 以得到更详细的信息。
7.	svn: Working copy 'trunk/src' locked svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)	异常操做致使目录没有解锁。  一个简单的重现方法：在 .svn 目录下建立空的名为 lock 的文件	使用命令行 "svn cleanup" 或者相似的“清理”动做删除锁定
	svn: 工做副本“trunk/src”已经锁定 svn: 运行“svn cleanup”删除锁定 (输入“svn help cleanup”获得用法)
8.	日志中没有做者信息： ------------------------------------ r9 | (没有做者信息) | … ossxp.com anonymous commit test	匿名提交致使没有做者信息	检查版本库权限控制,禁止匿名提交
9.	正在发送 ... 传输文件数据.svn: 提交失败(细节以下): svn: Commit blocked by pre-commit hook (exit code 1) with output: 提交说明至少应包含 4 个字符, 或者太简单了。	这是因为用户提交的提交说明(commit log)，太过简单了。在提交时须要输入有意义的 commit log。	写有意义的提交说明，或者请求管理员更改版本库插件
10.	增长 Logger.c 传输文件数据.svn: 提交失败(细节以下): svn: Commit blocked by pre-commit hook (exit code 1) with output: Wide character in print at /opt/svn/svnroot/myrepos/hooks/scripts/check-case-insensitive.pl line 259. 发现文件名大小写冲突: trunk/src/Logger.c 已经存在于 logger.c	管理员设置了对新增文件是否重名（只有大小写不一样）的文件进行检查。文件名只有大小写不一样，在Windows上进行检出会形成麻烦	不要添加剧名（仅大小写不一样）文件
	增长 src/文件aBc.txt 传输文件数据.svn: 提交失败(细节以下): svn: Commit blocked by pre-commit hook (exit code 1) with output: Clash: '/trunk/src/文件aBc.txt' '/trunk/src/文件abc.txt'
11.	svn: While preparing '/home/jiangxin/tmp/svn.test/trunk/src/README.txt' for commit svn: Inconsistent line ending style	提交的文件已经设置了 svn:eol-style 属性，可是该文本内的换行符有DOS的换行符CRLF，也有Unix换行符LF，不一致！	统一该文本文件内的换行符。Linux 下能够用dos2unix, unix2dos, sed等命令。Windows下可用 UltraEdit 进行转换。
	svn: 当为提交操做准备“/home/jiangxin/tmp/svn.test/trunk/src/README.txt”时 svn: 不一致的行结束样式
12.	svn: Failed to add file 'Makefile': an unversioned file of the same name already exists	执行更新(svn up)时报错。由于其余人新增一个文件到服务器，而本地却存在一个同名文件（未版本控制）	先将本地重名文件更名，再执行 "svn up"，以后再比较、合并文件。或者执行 "svn up --force"
	svn: 增长文件 'Makefile' 失败: 同名未版本控制的文件已存在
13.	Adding src/Makefile svn: Commit failed (details follow): svn: File '/svn/test/trunk/src/Makefile' already exists	添加新文件，提交时报错。由于其余人已经先于我增长了该文件。	先执行更新操做（"svn up"），再根据提示进行操做：合并/提交...
	增长 src/Makefile svn: 提交失败(细节以下): svn: 文件“/svn/test/trunk/src/Makefile”已存在
14.	$ svn up Conflict discovered in 'Makefile'. Select: (p) postpone, (df) diff-full, (e) edit, (mc) mine-conflict, (tc) theirs-conflict, (s) show all options: p C Makefile Updated to revision 5. Summary of conflicts: Text conflicts: 1	多人同时编辑同一个文件时，可能会遇到冲突。别人先于我提交，则当我提交时要先更新。更新可能遇到不能自动解决的冲突	使用工具进行冲突解决
	$ svn up 在 “Makefile” 中发现冲突。 选择: (p) 推迟，(df) 显示所有差别，(e) 编辑, (mc) 个人版本, (tc) 他人的版本, (s) 显示所有选项: p C Makefile 更新到版本 5。 冲突概要： 正文冲突：1
15.	svn: Commit failed (details follow): svn: File 'Makefile' is out of date svn: File not found: transaction '6-d', path '/trunk/src/Makefile'	提交的文件已被他人删除	先执行更新操做（"svn up"），再根据提示解决该树冲突：删除文件或继续添加...
	svn: 提交失败(细节以下): svn: 文件 “Makefile” 已通过时 svn: File not found: transaction '6-c', path '/trunk/src/Makefile'
16.	svn: Commit failed (details follow): svn: File or directory '/trunk/XXX' is out of date; try updating svn: resource out of date; try updating	基于旧版本修改是不容许的	先更新（"svn update"），再提交
	svn: 提交失败(细节以下): svn: 文件或目录 “/trunk/XXX” 已通过时；请先更新 svn: resource out of date; try updating
17.	svn: DAV request failed; it's possible that the repository's pre-revprop-change hook either failed or is non-existent svn: At least one property change failed; repository is unchanged svn: Error setting property 'log': Repository has not been enabled to accept revision propchanges; ask the administrator to create a pre-revprop-change hook	修改提交说明等操做属于高风险操做，由于该操做没有被版本控制，属于不可恢复的操做。缺省禁止。	请联系管理员，启用该版本的相关钩子，容许修改“版本属性”。参见 管理员钩子设置
	svn: DAV 请求失败；多是版本库的 pre-revprop-change 钩子执行失败或者不存在 svn: 至少有一个属性变动失败；版本库未改变 svn: 设置属性 “log” 出错: Repository has not been enabled to accept revision propchanges; ask the administrator to create a pre-revprop-change hook
18.	传输文件数据.svn: 提交失败(细节以下): svn: Commit blocked by pre-commit hook (exit code 1) with output: ==================== trunk/src/File.c : 属性 svn:mime-type 或者 svn:eol-style 没有设置 ==================== 管理员已经启用换行符属性检查。每个新添加的文件必须 指定换行符。若是 svn:mime-type 属性为文本文件，则 必须设置 svn:eol-style 属性。 对于二进制文件，执行以下命令： svn propset svn:mime-type application/octet-stream path/of/file 对于文本文件，能够执行以下命令： svn propset svn:mime-type text/plain path/of/file svn propset svn:eol-style native path/of/file 为了不每次添加文件手动设置，能够启用自动属性设置 ...	管理员启用了检查新文件换行符的扩展	为新增文件设置正确的 svn:mime-type 和/或 svn:eol-style 属性

2. TortoiseSVN 疑难解答

 

2.1. TortoiseSVN 不能安装？全部 MSI 格式的软件包都不能安装了！

问题描述: 在部署 Subversion 本地环境时，有位同事的机器始终没法安装 TortoiseSVN 安装包！ 据其本人讲，很早就已经发现不能安装 *.msi 格式软件包了，但是重装 Windows 损失太大。

解决方案: 最终发现是因为目录受权的问题：系统 system 帐号不能对目录进行写操做，当从新为目录设置安全权限后，解决该问题。

问题的解决过程以下：

经过 Windows 事件管理器查看到下面相关事件：

正在开始 Windows Installer 事务: E:安装工具版本控制TortoiseSVN-1.5.5.14361-win32-svn-1.5.4.msi。客户端进程 ID: 4488。 Product: TortoiseSVN 1.5.5.14361 (32 bit) -- Error 1305. Error reading from file E:安装工具版本控制TortoiseSVN-1.5.5.14361-win32-svn-1.5.4.msi. System error 1008. Verify that the file exists and that you can access it. 正在开始 Windows Installer 事务: E:安装工具版本控制TortoiseSVN-1.5.5.14361-win32-svn-1.5.4.msi。客户端进程 ID: 4488。 Product: TortoiseSVN 1.5.5.14361 (32 bit) -- Error 1305. Error reading from file E:安装工具版本控制TortoiseSVN-1.5.5.14361-win32-svn-1.5.4.msi. System error 1008. Verify that the file exists and that you can access it. Windows Installer 已安装产品。产品名称: TortoiseSVN 1.5.5.14361 (32 bit)。产品版本: 1.5.14361。产品语言: 1033。安装成功或错误状态: 1603。 Product: TortoiseSVN 1.5.5.14361 (32 bit) -- Installation failed.

为了查看 System error 1008 的错误含义，运行 net helpmsg 1008

C:> net helpmsg 1008 错误的引用令牌...

鼠标右键点击要安装的 *.msi 软件包所在的目录（本例为： E:安装工具版本控制），查看权限，发现：

除了管理员账号外，还有两个未知的用户账号；

未知的用户账号，多是因为Windows从新安装后，以前的Windows用户账号 Everyone 和 Administrators。

从新设置该目录的权限，为 Everyone 用户赋予 Full 权限；

从新运行 *.msi 安装包，成功安装。

参考连接:

http://www.appdeploy.com/msierrors/detail.asp?id=66

http://msdn.microsoft.com/en-us/library/cc185688(VS.85).aspx

http://www.microsoft.com/downloads/details.aspx?displaylang=zh-cn&FamilyID=889482fc-5f56-4a38-b838-de776fd4138c

2.2. 为何提交者不是我？如何修改 TortoiseSVN 的提交用户的身份？

TortoiseSVN 缓存了认证信息，即缺省使用上一次认证成功的用户名和口令进行提交。 若是其余人在本身的机器上进行提交（以对方的身份认证），则本机提交都使用其余人的用户帐号。 这除了形成提交者信息发生错误外，还会形成安全问题──帐号权限可能被滥用。

解决办法：

打开相关对话框：TortoiseSVN -> 设置 -> 已保存数据

清除认证数据

2.3. 为何我不能像在培训中老师操做的那样反删除？个人菜单中甚至没有相关的菜单选项？

培训中演示了反删除，其中一种方法为：

在工做目录中，右键单击鼠标，选择查看日志

在日志中选择要恢复的相关历史操做，右键单击，选择“复原此版本中的变动”

自动经过一个反向合并操做完成文件的反删除

在本地目录中执行提交操做，才最终完成反删除

然而，有的学员在实际操做中，第二步操做中的日志对话框的菜单中出现不了“复原此版本中的变动”！

原来问题出在第一步。

正确的操做是：右键点击工做区目录，在弹出的菜单中选择“查看日志”

错误的操做是：右键点击工做区目录，在弹出的菜单中选择“版本库浏览器”。而后在弹出的“版本库浏览器”对话框中，再点击对应目录，选择“查看日志”。

这就难怪了。反删除或者合并操做，是在本地工做目录完成的。而“版本库浏览器”是直接操做服务器，没有一个本地目录相对应，所以菜单中不会出现只有对应本地目录才能出现的命令。

2.4. 哪一个代码比较工具好用？而且能够进行图形化的冲突解决？

Kdiff3 是一个很是好的选择。Kdiff3 本来是 Linux 的 KDE 图形环境下的一个文件比较和冲突解决工具， 支持三向文件比较，已经被移植到了 Windows 平台。在 Windows 中安装，会自动设置 TortoiseSVN 的相关命令行参数。

下面是 Kdiff3 的一个文件合并的界面：

 可是 Kdiff3 对中文支持存在必定的问题，中文的显示会重叠在一块儿，形成识别上的困难。能够经过设置字体（Marlett, 微软雅黑等），使得中文可以显示彻底，可是英文则按照全角显示。

还有其余的比较/冲突解决工具能够选择：

TortoiseMerge: TSVN 自带的缺省冲突解决工具。

Araxis Merge: Windows 平台上的商业软件，支持目录和文件的比较。

Meld： Linux 上的文件比较工具

2.5. 没法用 VS.net 2003 打开用 Subversion 检出的项目？

这是 VS.Net 2003 的一个Bug。即只要项目下存在以 点开头的文件或文件夹，使用了 FrontPage 扩展的 VS.NET 2003 项目就在打开项目的界面发生死锁，致使项目没法打开。

若是项目自己不存在兼容性问题，尽可能将 VisualStdio .Net 升级为高版本，如 VS.NET 2005,2008 或更高。

若是因为兼容性问题，或者因为客户的平台不能轻易升级等缘由，须要使用 VS.NET 2003 的开发环境。Subversion 提供了一个解决方案。

Subversion 提供的解决方案就是，使用 _svn （如下划线开头的目录而非点开头的目录）做为工做区的控制目录，取代 .svn

在 TSVN 中经过下面的对话框进行设置

注意：在设置了 Subversion 使用 _svn 做为控制目录后，以前以 .svn 做为控制目录检出的工做区将再也不有效！反之亦然。

3. 其余IDE 整合疑难解答

 

3.1. 报错： 工做区版本太新

这是因为安装了多个 Subversion 客户端，然而各个 Subversion 客户端软件的版本不一样（大版本不一样）。

若是同时安装了 TortoiseSVN 和 Subclipse，若是工做区被高版本的 TSVN 访问，工做区格式则自动更新为最新的格式， 会致使低版本的客户端，如 Subclipse 没法访问。

解决办法：

将全部的 Subversion 客户端版本都升级到同一个大的版本，这样就不会形成工做区版本冲突了。

或者，若是有的客户端还没有推出新版本，则只能在多个客户端选择一个最经常使用的，其余不经常使用的卸载。

 

3.2. 没法安装 AnknSVN 的 MSI 格式安装包?

参见： TortoiseSVN 不能安装？全部 MSI 格式的软件包都不能安装了！

3.3. 个人机器同时部署了 VS.NET 2003 和 VS.NET 2008，可以安装 AnkhSVN 么？

能够在一台机器中同时安装多个版本的 AnkhSVN。

AnknSVN 事先将 Subversion 整合在 VS.NET 中。对于不一样的版本的 VS.NET，须要安装不一样版本库的 AnkhSVN。

对于 VS.NET 2003，须要安装 AnkhSVN 1.0.x 版本

对于 VS.NET 2005,2008 以上版本，须要安装 AnkhSVN 2.0 以上版本

4. SVN统计疑难解答

 

4.1. 为何 Subversion 代码分析工具得出的代码行统计和开发工具统计出来的相差不少？

有的同事发现用开发工具统计出来的代码行统计值比较低，而 Subversion 代码分析工具得出的代码行统计却高的离谱。针对这个问题，用下列工具作了测试。

代码行统计工具一览：

在对代码行工具进行核实的过程当中，参考了下列工具：

cloc.pl: 参见 http://cloc.sourceforge.net/

wc : Unix 命令。

sloccount: 支持的语言有限。

最终得出的结论是： 在 Statsvn 提供的 Subversion 代码统计页面中，会出现两个不一样的代码行概念：一个是历史代码行，一个是实际代码行。实际代码行和用户开发工具统计值基本相符，历史代码行是一个动态的概念，可能要远远高出实际代码行。

历史代码行

包含了对删除文件的统计，还包含了对代码中删除/修改的行的统计。是版本库特有的代码行统计量。由于当前最新代码的实际代码行，并不能表明实际工做量，而整个的代码变动历史（包含代码删除和代码修改）才能真正的反映工做量。

实际代码行

就是咱们常说的代码行数统计量，是当前版本库中最新代码的代码量。不包含历史更改。

测试数据略...

5. 管理员疑难解答

 

5.1. 如何建立一个新的版本库？

建立版本库

用超级用户帐号，登陆 Subversion 管理后台，在菜单中选择 “版本管理”

点击连接 “添加版本库”

输入版本库名称，完成建立

 对于新建立的版本库（即没有任何代码提交），能够经过管理员界面删除新建的版本库

为版本库指定管理员（版本库管理员只有对本版本库进行权限设置/版本库管理等功能）

在菜单中选择 “权限管理”

在下拉菜单选择新建立的版本库

在管理员文本框，输入用逗号分隔的管理员ID列表

后续步骤

通知项目经理，版本库已经完成建立

项目经理或者由项目经理指派管理员完成版本库的受权

参见 权限分配

还有版本库的插件配置也应该由项目经理配置完成

参见 版本库功能扩展

5.2. 如何为版本库添加功能扩展？

Subversion 经过钩子脚本实现功能扩展。管理员能够经过图形界面为版本库设置功能扩展。

如何访问 Subversion 插件管理界面？

在浏览器中输入 Subversion 后台管理 URL，如： http://dev.moon.ossxp.com/pysvnmanager/

输入管理员的用户名和口令

从功能菜单中选择 “版本库管理”

选择相应的版本库

如图所示：

如何添加功能扩展？

在还没有安装的插件列表中，选择要安装的插件

填写必要的参数后，点击按钮 “安装此插件”

如何删除功能扩展？

选择功能扩展前的选择框

点击页面下方的 “删除选择的插件” 按钮

如何修改/从新配置功能扩展？

在当前插件配置列表中，每一个差价的 ID 均可以点击，点击对应插件的英文 ID

该插件的配置界面出如今页面的上方

修改完成后，点击按钮 “安装此插件”

5.2.1. AllowRevpropChange: 容许修改版本属性

版本属性

版本属性是附着于版本提交的属性，即提交事件自己的属性，如：提交说明、提交者ID等等。和 Subversion 通常的属性概念不一样，“版本属性”没有版本控制，一但修改不可恢复，不像 Subversion 的通常属性每次修改都要提交，于是通常属性被版本控制，修改不会破坏历史。

修改版本属性属于不可恢复动做，所以默认是禁用的。本插件能够开放对版本属性的修改。 若是经过本插件启用，最好启用 变动邮件通知 插件，使得版本属性的修改可以经过邮件发送出来，起到对原有版本属性存档以及通知的做用。

可选参数:

无

5.2.2. CapCheckMergeInfo: 禁止低版本的 SVN 客户端访问

Subversion 1.5 提供了合并追踪功能，若是用旧的 SVN 客户端( < 1.5.0 )访问，会形成对 Subversion 合并追踪的破坏。

启用此插件，会禁止低版本的 SVN 客户端提交。

可选参数:

无

5.2.3. CaseInsensitive: 检查大小写引发的文件名冲突

Subversion 自己对版本控制的文件、目录等是大小写区分的，这对于像 Windows 那样的对文件/目录名大小写不区分的文件系统来讲，会出现混乱的状况。

若是在同一个目录下提交了两个同名文件（仅仅大小写不一样）

在文件系统大小写不敏感的操做系统（如 Windows上），会形成文件的相互覆盖等各类古怪的现象

该插件经过在提交时，检查版本库中现有的文件，若是发现同名（仅大小写不一样）文件，则终止提交，报错。

可选参数:

无

5.2.4. CommitLogCheck: 检查提交说明

缺省 Subversion 自己不进行提交说明检查，用户能够不写提交说明（commit log）提交。不写提交说明是很是很差的习惯。

怎样才是好的提交说明（Commit Log）？

不要写冗余的信息。提交事件自己会包含：提交者ID，提交时间，提交的文件名称，代码的 differ 等。下列的提交说明包含冗余信息，不是合格的提交说明：

"本代码由 jiangxin 提交" （提交者ID是冗余信息）

"今天 2009-01-01 提交" （提交时间是冗余信息）

"添加文件 hello.cpp " （提交的文件名也是冗余信息）

提交说明能够包含：为什么作出更改 ── 实现了哪一个功能需求，改正了哪一个 Bug？

提交说明能够包含：为什么如此更改 ── 实现中用到的技巧

提交说明有可能要比代码更改量还要多

可选参数:

启用或关闭插件

为了不经过删除插件禁用而形成的配置信息丢失，该插件能够经过设置启用/中止按钮来启用和关闭插件。

提交说明的最小长度

输入大于 0 的整数。若是提交说明的字符数小于该值，则禁止提交。

匹配的模板

提交说明中必须包含的字符，如： (bug|issue)。缺省为空。

不能出现的内容

禁止在提交说明中出现的内容，缺省为空。

5.2.5. EmailNotify: 针对代码变动发出邮件通知

版本库中的数据变动（文件修改或者属性修改），发出通知邮件。缺省为空。

若要启用该插件，须要为邮件通知设置参数： 一个由多个命令行参数组成的一行文本做为该插件的参数。格式为

[options] email_addr [email_addr ...]

或者基于正则表达式，提供一个基于路径的代码变动的邮件通知。

[-m regex1] [options] [email_addr ...] [-m regex2] [options] [email_addr ...] ...

参数：

-m regex

和提交路径相匹配的正则表达式。一个点 "." 匹配全部路径

--from email_address

发信人地址

-r email_address

回复邮件地址

-s subject_prefix

标题的前缀，如 [Prefix]

--diff n

不包含代码差别（缺省包含）

示例:

全部代码变动发送一个只读的邮件列表： project1-commit@list.moon.ossxp.com， 回复地址设置为另一个可写（容许讨论）的邮件列表： project1-discuss@list.moon.ossxp.com

--from noreply@moon.ossxp.com -r project1-discuss@list.moon.ossxp.com -s [DEV] project1-commit@list.moon.ossxp.com

不包含代码差别的邮件发送到一个邮件列表，包含代码差别的邮件发送到另外的一个邮件列表

-m . --from noreply@moon.ossxp.com -r project1-discuss@list.moon.ossxp.com -s [DEV] --diff n project1-commit@list.moon.ossxp.com -m . --from noreply@moon.ossxp.com -r project1-discuss@list.moon.ossxp.com -s [DEV] --diff y project1-commit-with-diff@list.moon.ossxp.com

5.2.6. EolStyleCheck: 文件类型和换行符设置检查

若是启用该插件，则新增的文件，必须设置 svn:mime-type 和/或 svn:eol-style 属性。

当新增长的文件的 svn:mime-type 属性以 "text/" 开头，或者没有设置，则该文件必须设置 svn:eol-style 属性，以标识该文本文件的换行符属性。

为什么要设置文本文件的换行符属性？

为了更好的跨平台开发，须要设置文本文件的换行符属性。有如下几种状况：

若是当前的项目正在跨平台开发（Windows 和 Linux），有的员工工做在一个平台上，有的工做在另外的操做系统上

或者当前项目的开发语言支持跨平台开发（如： Java, Python, PHP, C, ...）

或者当前项目是在 Linux 下开发而有的开发人员喜欢在 Windows下编辑（反之亦然）

对提交文件进行换行符检查，避免出现混杂的换行符出现

可选参数:

无

5.2.7. ReadonlySvnMirror: SVN 工做在只读镜像模式，禁止用户写入

该扩展是为 Subversion 分布式部署而存在的。当 Subversion 主服务器位于远程网络，本地能够创建本地镜像而提供本地般的访问速度。 但要限制用户对该镜像服务器的访问，只有负责镜像的专用帐号，才可以在镜像服务器中提交。

可选参数:

启用或关闭插件。为了不经过删除插件禁用而形成的配置信息丢失，该插件能够经过设置启用/中止按钮来启用和关闭插件。

Svnsync 管理员: 仅该帐号能够提交到该只读 Subversion 镜像库。

5.2.8. TracPostCommit: Trac 与 SVN 整合

整合 SVN 与 trac（需求和缺陷跟踪系统）。若是 subversion 的提交说明包含 ticket id，则更新对应 trac 实例的 ticket 状态，将提交说明附加到 ticket 后。

可选参数:

启用或关闭插件

为了不经过删除插件禁用而形成的配置信息丢失，该插件能够经过设置启用/中止按钮来启用和关闭插件。

Trac 环境路径

根据 trac 实例的部署，如实填写

此版本库 trac 中的名称（缺省为空）

若是对应的 Trac 实例配置了多个版本库，则需提供对应的版本库别名。缺省为空。

标记为修复的ticket状态

当提交代码标记为修复对应的 ticket（需求或者bug），Trac 中该 ticket 的状态设置为该值。缺省为为空（即 closed）

5.3. 为新员工分配Subversion帐号的过程是如何的？

经过集中管理平台建立新帐号。如图所示：

该操做通常由系统管理员（帐号管理员）执行

只需建立一次帐号，用户就自动在各个业务子系统拥有帐号。若是用户帐号已经创建，跳过此步骤。

 注意：从事先定义好的用户模板建立新用户帐号，能够避免因为用户组设置错误，致使用户不能更改口令，或者用户不能访问 Subversion 服务。

访问 Subversion 管理后台，为用户分配权限。如图所示：

该操做通常由具体项目的管理员或者项目经理执行

5.4. 拆除“核弹引爆码”？

核弹引爆码

是一个有趣的比喻。若是很是隐私数据或其它不该该出如今版本库中的数据（如“核弹引爆码”），不当心提交（检入）到了版本库。若是用版本库自身的删除功能，只是在表面删除而已，该“核弹引爆码”仍然能够经过访问版本库历史而查看到。从安全角度上讲，是不容许的，应该从版本库中完全删除 ── 历史中也不可见。

Subversion 可以完全删除“核弹引爆码”，可是普通用户不行，须要管理员进行操做。（这很合理，由于版本库安全性的另外一方面，就是数据的绝对安全 ── 一旦提交，历史不可更改）

操做的过程以下：

用 "svnadmin dump" 命令导出版本库到一个文件

用 "svndumpfilter" 命令过滤掉导出文件中的“核弹引爆码”文件

再建立一个新库，用 "svnadmin load" 命令从导出文件重建版本库

删除旧版本库，将新版本库目录更名为原版本库名称

 注意：确保新版本库的 UUID 不变，版本库的提交版本的编号顺序也不变，整个操做对版本库的使用者将是透明的。

参见： 管理员命令行参考

5.5. 一个版本库拆分为多个？多个版本合并为一个？

参见： 管理员命令行参考

5.6. 版本库从 CVS 到 Subverson 迁移？

参见： cvs2svn 手册