svn常见问题

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

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

原因分析:

问题的实质是 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 版本库做示例，仅供参考。

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” 中

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)

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” 中

svn: OPTIONS of ‘http://www.moon.ossxp.com/svn/test‘: 200 OK (http://www.moon.ossxp.com)

svn: 方法 OPTIONS 失败于 “http://www.moon.ossxp.com/svn/test”: 200 OK (http://www.moon.ossxp.com)

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!

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: 此客户端对于工作副本 “.” 太旧。你需要取得更新的 Subversion 客户端，或者降级工作副本。 参见 http://subversion.tigris.org/faq.html#working-copy-format-change 以获得更详细的信息。

svn: Working copy ‘trunk/src‘ locked svn: run ‘svn cleanup‘ to remove locks (type ‘svn help cleanup‘ for details)

svn: 工作副本“trunk/src”已经锁定 svn: 运行“svn cleanup”删除锁定 (输入“svn help cleanup”得到用法)

日志中没有作者信息： ------------------------------------ r9 | (没有作者信息) | … ossxp.com anonymous commit test

正在发送 ... 传输文件数据.svn: 提交失败(细节如下): svn: Commit blocked by pre-commit hook (exit code 1) with output: 提交说明至少应包含 4 个字符, 或者太简单了。

增加 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

增加 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‘

svn: While preparing ‘/home/jiangxin/tmp/svn.test/trunk/src/README.txt‘ for commit svn: Inconsistent line ending style

svn: 当为提交操作准备“/home/jiangxin/tmp/svn.test/trunk/src/README.txt”时 svn: 不一致的行结束样式

svn: Failed to add file ‘Makefile‘: an unversioned file of the same name already exists

svn: 增加文件 ‘Makefile‘ 失败: 同名未版本控制的文件已存在

Adding src/Makefile svn: Commit failed (details follow): svn: File ‘/svn/test/trunk/src/Makefile‘ already exists

增加 src/Makefile svn: 提交失败(细节如下): svn: 文件“/svn/test/trunk/src/Makefile”已存在

$ 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

svn: Commit failed (details follow): svn: File ‘Makefile‘ is out of date svn: File not found: transaction ‘6-d‘, path ‘/trunk/src/Makefile‘

svn: 提交失败(细节如下): svn: 文件 “Makefile” 已经过时 svn: File not found: transaction ‘6-c‘, path ‘/trunk/src/Makefile‘

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: 提交失败(细节如下): svn: 文件或目录 “/trunk/XXX” 已经过时；请先更新 svn: resource out of date; try updating

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

传输文件数据.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 为了避免每次添加文件手动设置，可以启用自动属性设置 ...

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 手册