Subversion 版本库整理实战
在使用 svnadmin dump, svnadmin load, svndumpfilter 等命令对 Subversion 版本库裁减，可真的不是 a piece of cake. 有很多技巧，窍门和陷阱。
这不，今天一个客户的电话，就涉及到了 svn 版本库裁减的好些问题：
- svndumpfilter 命令后面的 include 或者 exclude 子语句，后面的多个路径用逗号分割可以么？
- svndumpfilter 命令后面的 include 或者 exclude 子语句，后面的路径可以使用通配符么？如何使用？
- svndumpfilter 命令涉及的路径非常多，在命令行写太复杂了，甚至可能超过 SHELL 对命令行长度的限制，该如何？
- 重新整理的版本库为什么有很多空的提交，说是为了占位之用？
- 重新整理后的版本库的路径可以改变么？
简要回答
客户的实际需求是将几十个GB的代码库，将某一个或某几个分支拆分出来形成新的版本库。但是在执行 svndumpfilter 后产生的过滤文件只有几十MB，而且在导入到新版本库后，版本库当中无内容，只有空的提交。
后来查看客户的命令，发现 svndumpfilter 命令的格式不正确，include 或者 exclude 子命令的参数是一个路径列表，这个路径列表应该用空格分隔，而不能用逗号。
还有：路径不支持通配符，因此需要一个一个的写，如果太多，可以放在一个文件中，用回车符分割。
在命令行中应该用空格分割包含或者排除的路径列表。看看 svndumpfilter 的这段代码：
if (subcommand->cmd_func != subcommand_help)
{
opt_state.prefixes = apr_array_make(pool, os->argc - os->ind,
sizeof(const char *));
for (i = os->ind ; i< os->argc; i++)
{
const char *prefix;
/* Ensure that each prefix is UTF8-encoded, in internal
style, and absolute. */
SVN_INT_ERR(svn_utf_cstring_to_utf8(&prefix, os->argv[i], pool));
prefix = svn_path_internal_style(prefix, pool);
prefix = svn_path_join("/", prefix, pool);
APR_ARRAY_PUSH(opt_state.prefixes, const char *) = prefix;
}- 将 os->argv 的数组转换为列表。即：用空格分割各个包含或者排除的路径
- prefix 进行了整理，包括在前面增加 “/” 字符，就是说路径前面的 “/” 字符可有可无
如果包含或者排除的路径太长，可以将路径写入文件中，用 –targets target_file 指定。参见下面 svndumpfilter 的代码片段：
if (opt_state.targets_file)
{
svn_stringbuf_t *buffer, *buffer_utf8;
const char *utf8_targets_file;
/* We need to convert to UTF-8 now, even before we divide
the targets into an array, because otherwise we wouldn't
know what delimiter to use for svn_cstring_split(). */
SVN_INT_ERR(svn_utf_cstring_to_utf8(&utf8_targets_file,
opt_state.targets_file, pool));
SVN_INT_ERR(svn_stringbuf_from_file2(&buffer, utf8_targets_file,
pool));
SVN_INT_ERR(svn_utf_stringbuf_to_utf8(&buffer_utf8, buffer, pool));
opt_state.prefixes = apr_array_append(pool,
svn_cstring_split(buffer_utf8->data, "\n\r", TRUE, pool),
opt_state.prefixes);
}其含义为：
- 如果在 include 或者 exclude 语句包含路径列表太长，可以将包含路径写入文件，使用 –targets 命令指向该文件
- 在该文件中，用回车键分割各个路径
- 在该文件中，除了路径不能有其他参数
一个不太简单的例子
要求：一个版本库（包含 /trunk, /branches/1.x, /tags/1.0），只将其中的分支 /branches/1.x 导出
1. 先初始化示例版本库，包含主线 /trunk, 分支 /tags/1.0 和 /branches/1.x
/tmp/svn$ svnadmin create repos /tmp/svn$ svn co file:///tmp/svn/repos work 取出版本 0。 /tmp/svn$ cd work/ /tmp/svn/work$ mkdir trunk branches tags /tmp/svn/work$ svn add * A branches A tags A trunk /tmp/svn/work$ svn ci -m "初始化项目目录" 增加 branches 增加 tags 增加 trunk 提交后的版本为 1。 /tmp/svn/work$ cd trunk /tmp/svn/work/trunk$ mkdir src doc /tmp/svn/work/trunk$ echo hello > readme.txt /tmp/svn/work/trunk$ echo source file > src/hello.c /tmp/svn/work/trunk$ svn add * A doc A doc/api.txt A readme.txt A src A src/hello.c /tmp/svn/work/trunk$ svn ci -m "文件初始化" 增加 trunk/doc 增加 trunk/doc/api.txt 增加 trunk/readme.txt 增加 trunk/src 增加 trunk/src/hello.c 传输文件数据... 提交后的版本为 2。 /tmp/svn/work/trunk$ date >> readme.txt /tmp/svn/work/trunk$ date >> src/hello.c /tmp/svn/work/trunk$ svn st M src/hello.c M readme.txt /tmp/svn/work/trunk$ svn ci -m "修改文件..." 正在发送 trunk/readme.txt 正在发送 trunk/src/hello.c 传输文件数据.. 提交后的版本为 3。 /tmp/svn/work/trunk$ cd .. /tmp/svn/work$ svn cp trunk branches/1.x A branches/1.x /tmp/svn/work$ svn ci -m "创建分支 1.x" 增加 branches/1.x 增加 branches/1.x/doc 增加 branches/1.x/readme.txt 增加 branches/1.x/src 增加 branches/1.x/src/hello.c 提交后的版本为 4。 /tmp/svn/work$ svn cp trunk tags/1.0.0 A tags/1.0 /tmp/svn/work$ svn ci -m "创建里程碑 1.0" 增加 tags/1.0 增加 tags/1.0/doc 增加 tags/1.0/readme.txt 增加 tags/1.0/src 增加 tags/1.0/src/hello.c 提交后的版本为 5。 /tmp/svn/work$ cd branches/1.x/ /tmp/svn/work/branches/1.x$ echo branch >> readme.txt /tmp/svn/work/branches/1.x$ svn ci -m "分支中修改 readme.txt" 正在发送 1.x/readme.txt 传输文件数据. 提交后的版本为 6。 /tmp/svn/work/branches/1.x$ echo branch >> src/hello.c /tmp/svn/work/branches/1.x$ svn ci -m "分支中修改 hello.c" 正在发送 1.x/src/hello.c 传输文件数据. 提交后的版本为 7。 /tmp/svn/work/branches/1.x$ cd ../trunk/ /tmp/svn/work/trunk$ ls doc readme.txt src /tmp/svn/work/trunk$ echo new api >> doc/api.txt /tmp/svn/work/trunk$ svn ci -m "new 主线中增加" 正在发送 trunk/doc/api.txt 传输文件数据. 提交后的版本为 8。 /tmp/svn$ svn log file:///tmp/svn/repos ------------------------------------------------------------------------ r8 | jiangxin | 2010-01-27 11:00:18 +0800 (三, 2010-01-27) | 1 行 主线中增加 new api ------------------------------------------------------------------------ r7 | jiangxin | 2010-01-27 10:59:17 +0800 (三, 2010-01-27) | 1 行 分支中修改 hello.c ------------------------------------------------------------------------ r6 | jiangxin | 2010-01-27 10:59:05 +0800 (三, 2010-01-27) | 1 行 分支中修改 readme.txt ------------------------------------------------------------------------ r5 | jiangxin | 2010-01-27 10:58:33 +0800 (三, 2010-01-27) | 1 行 创建里程碑 1.0 ------------------------------------------------------------------------ r4 | jiangxin | 2010-01-27 10:58:12 +0800 (三, 2010-01-27) | 1 行 创建分支 1.x ------------------------------------------------------------------------ r3 | jiangxin | 2010-01-27 10:57:42 +0800 (三, 2010-01-27) | 1 行 修改文件... ------------------------------------------------------------------------ r2 | jiangxin | 2010-01-27 10:57:15 +0800 (三, 2010-01-27) | 1 行 文件初始化 ------------------------------------------------------------------------ r1 | jiangxin | 2010-01-27 10:55:58 +0800 (三, 2010-01-27) | 1 行 初始化项目目录 ------------------------------------------------------------------------
2. 导出版本4到版本7的数据到导出文件
通过 log 可以看出和 branches/1.x 相关的提交只是从第4个版本到第7个版本，于是只导出这些版本到 dumpfile
/tmp/svn$ svnadmin dump /tmp/svn/repos -r4:7 > r4-7.dump * 已转存版本 4。 警告: 版本 1 的参考数据比最旧的转存数据版本 (4)还旧。 警告: 装载这个转存到空的版本库会失败。 警告: 版本 2 的参考数据比最旧的转存数据版本 (4)还旧。 警告: 装载这个转存到空的版本库会失败。 警告: 版本 3 的参考数据比最旧的转存数据版本 (4)还旧。 警告: 装载这个转存到空的版本库会失败。 警告: 版本 2 的参考数据比最旧的转存数据版本 (4)还旧。 警告: 装载这个转存到空的版本库会失败。 警告: 版本 3 的参考数据比最旧的转存数据版本 (4)还旧。 警告: 装载这个转存到空的版本库会失败。 * 已转存版本 5。 * 已转存版本 6。 * 已转存版本 7。
3. 新版本库由 r4-8.dump 加载失败
从上一步导出的 r4-7.dump 导入到新版本库。
/tmp/svn$ svnadmin create newrepos /tmp/svn$ svnadmin load newrepos < r4-7.dump <<< 开始新的事务，基于原始版本 4 * 正在增加路径: trunk ...完成。 * 正在增加路径: trunk/doc ...完成。 * 正在增加路径: trunk/doc/api.txt ...完成。 * 正在增加路径: trunk/src ...完成。 * 正在增加路径: trunk/src/hello.c ...完成。 * 正在增加路径: trunk/readme.txt ...完成。 * 正在增加路径: branches ...完成。 * 正在增加路径: branches/1.x ...完成。 * 正在增加路径: branches/1.x/doc ...完成。 * 正在增加路径: branches/1.x/doc/api.txt ...完成。 * 正在增加路径: branches/1.x/src ...完成。 * 正在增加路径: branches/1.x/src/hello.c ...完成。 * 正在增加路径: branches/1.x/readme.txt ...完成。 * 正在增加路径: tags ...完成。 ------- 提交新版本 1 (从原始版本 4 装载) >>> <<< 开始新的事务，基于原始版本 5 svnadmin: 当前版本库不存在相对源版本 -2 * 正在增加路径: tags/1.0 ... /tmp/svn$ svn log file:///tmp/svn/newrepos ------------------------------------------------------------------------ r1 | jiangxin | 2010-01-27 10:58:12 +0800 (三, 2010-01-27) | 1 行 创建分支 1.x ------------------------------------------------------------------------
导入出错，这是为什么呢？因为在导出包含的 r5 ，是从 trunk 版本 2 创建里程碑 1.0，因为我们的导出是从版本4开始的，不包含版本2，因此导致 r5 的导出记录导入出错。
4. 对 r4-7.dump 过滤，只包含 branches 内容，再导入，成功
/tmp/svn$ svnadumpfilter --drop-empty-revs --renumber-revs include branches < r4-7.dump > branch_only.dump 包含 (以及丢弃空版本) 的前缀: '/branches' 版本 4 提交为 4。 跳过版本 5。 版本 6 提交为 5。 版本 7 提交为 6。 删除 1 个版本。 版本被重新编号如下: 7 => 6 6 => 5 5 => (丢弃) 4 => 4 丢弃 12 个节点: '/tags' '/tags/1.0' '/tags/1.0/doc' '/tags/1.0/readme.txt' '/tags/1.0/src' '/tags/1.0/src/hello.c' '/trunk' '/trunk/doc' '/trunk/doc/api.txt' '/trunk/readme.txt' '/trunk/src' '/trunk/src/hello.c' /tmp/svn$ rm -rf newrepos /tmp/svn$ svnadmin create newrepos /tmp/svn$ svnadmin load newrepos < branch_only.dump
5. 新版本库中的路径由 branches/1.x 修改为 trunk，如何操作？
按照上面的步骤，创建的新版本库中的路径都是在 branches/1.x ，如下：
/tmp/svn$ svn log file:///tmp/svn/newrepos ------------------------------------------------------------------------ r3 | jiangxin | 2010-01-27 10:59:17 +0800 (三, 2010-01-27) | 1 行 分支中修改 hello.c ------------------------------------------------------------------------ r2 | jiangxin | 2010-01-27 10:59:05 +0800 (三, 2010-01-27) | 1 行 分支中修改 readme.txt ------------------------------------------------------------------------ r1 | jiangxin | 2010-01-27 10:58:12 +0800 (三, 2010-01-27) | 1 行 创建分支 1.x ------------------------------------------------------------------------ /tmp/svn$ svn ls -R file:///tmp/svn/newrepos branches/ branches/1.x/ branches/1.x/doc/ branches/1.x/doc/api.txt branches/1.x/readme.txt branches/1.x/src/ branches/1.x/src/hello.c
如果创建过程中对导出文件进行进一步的处理，就可以实现新版本中，提交都在 /trunk 而非 branches 中：
查看导出文件中 Node-path 字段，同时输出行号：
/tmp/svn$ grep -n "^Node-path" branch_only.dump 23:Node-path: branches 32:Node-path: branches/1.x 41:Node-path: branches/1.x/doc 50:Node-path: branches/1.x/doc/api.txt 71:Node-path: branches/1.x/src 80:Node-path: branches/1.x/src/hello.c 102:Node-path: branches/1.x/readme.txt 142:Node-path: branches/1.x/readme.txt 173:Node-path: branches/1.x/src/hello.c
过滤掉 branches 目录创建相关内容，因为我们需要的是 branches/1.x 开始的内容
/tmp/svn$ head -22 branch_only.dump > top /tmp/svn$ tail -n +32 branch_only.dump > tail /tmp/svn$ cat top tail > branch_only_strip.dump /tmp/svn$ grep -n "^Node-path" branch_only_strip.dump 23:Node-path: branches/1.x 32:Node-path: branches/1.x/doc 41:Node-path: branches/1.x/doc/api.txt 62:Node-path: branches/1.x/src 71:Node-path: branches/1.x/src/hello.c 93:Node-path: branches/1.x/readme.txt 133:Node-path: branches/1.x/readme.txt 164:Node-path: branches/1.x/src/hello.c
对导出文件的内容进行字符串替换，将 branches/1.x 替换为 trunk
/tmp/svn$ sed -e "s@^\(Node-path: \|Node-copyfrom-path: \)branches/1.x@\1trunk@" branch_only_strip.dump > new_trunk.dump /tmp/svn$ grep -n "^Node-path" new_trunk.dump 23:Node-path: trunk 32:Node-path: trunk/doc 41:Node-path: trunk/doc/api.txt 62:Node-path: trunk/src 71:Node-path: trunk/src/hello.c 93:Node-path: trunk/readme.txt 133:Node-path: trunk/readme.txt 164:Node-path: trunk/src/hello.c
使用字符串替换之后的导出文件 (new_trunk.dump)，导入到新版本中
/tmp/svn$ rm -rf newrepos/ /tmp/svn$ svnadmin create newrepos /tmp/svn$ svnadmin load newrepos < new_trunk.dump <<< 开始新的事务，基于原始版本 4 * 正在增加路径: trunk ...完成。 * 正在增加路径: trunk/doc ...完成。 * 正在增加路径: trunk/doc/api.txt ...完成。 * 正在增加路径: trunk/src ...完成。 * 正在增加路径: trunk/src/hello.c ...完成。 * 正在增加路径: trunk/readme.txt ...完成。 ------- 提交新版本 1 (从原始版本 4 装载) >>> <<< 开始新的事务，基于原始版本 5 * 正在修改路径: trunk/readme.txt ...完成。 ------- 提交新版本 2 (从原始版本 5 装载) >>> <<< 开始新的事务，基于原始版本 6 * 正在修改路径: trunk/src/hello.c ...完成。 ------- 提交新版本 3 (从原始版本 6 装载) >>> /tmp/svn$ svn log file:///tmp/svn/newrepos 3 | jiangxin | 2010-01-27 10:59:17 +0800 (三, 2010-01-27) | 1 行 分支中修改 hello.c ------------------------------------------------------------------------ r2 | jiangxin | 2010-01-27 10:59:05 +0800 (三, 2010-01-27) | 1 行 分支中修改 readme.txt ------------------------------------------------------------------------ r1 | jiangxin | 2010-01-27 10:58:12 +0800 (三, 2010-01-27) | 1 行 创建分支 1.x ------------------------------------------------------------------------ /tmp/svn$ svn ls -R file:///tmp/svn/newrepos trunk/ trunk/doc/ trunk/doc/api.txt trunk/readme.txt trunk/src/ trunk/src/hello.c /tmp/svn$ exit
下面是相关版本库整理相关命令的手册，摘抄自：群英汇版本控制帮助中心
版本库整理相关命令
1. 导出 ── svnadmin dump
- svnadmin dump
- 该命令将版本库导出到一个格式文件，该导出文件包含所有版本库历史信息，可以用于版本库备份，或导入其它版本库。
用法：
svnadmin dump REPOS_PATH [-r LOWER[:UPPER]] [--incremental] [-q]
参数：
- REPOS_PATH必须是本地路径
如： /opt/svn/svnroot/repos2/- REPOS_PATH必须是本地路径
- -r LOWER[:UPPER]
- 导出从版本 LOWER 到版本 UPPER（或仅导出 LOWER 版本，如果UPPER不提供）的版本库历史。如果不提供该参数，则导出全部历史。
- –incremental
- 导出的第一个版本是和前一次版本的变更，用于增量备份和导入。如果不提供该参数，第一个导出版本是完整内容。
- -q
- 在标准错误输出不显示进度 (仅错误)
- –help
- 查看 svnadmin dump 命令的用法
示例：
$ svnadmin dump /opt/svn/svnroot/repos2 > dumpfile.txt
2. 导入 ── svnadmin load
- svnadmin load
- 从标准输入读取版本库转存（导出）的格式文件，并导入到新版本库中。
用法：
svnadmin load [--ignore-uuid|--force-uuid] [--use-pre-commit-hook] [--use-post-commit-hook] [--parent-dir ARG] REPOS_PATH
参数：
- REPOS_PATH
- 必须是本地路径。如： /opt/svn/svnroot/repos2/。如果是空版本库（即刚刚用 svnadmin create 创建），则会用标准输入流中的 UUID 替换该库的 UUID。
- –ignore-uuid
- 即使目标版本库是空的，也不用标准输入流中的 UUID 替换版本库的 UUID。
- –force-uuid
- 即使目标版本库非空（含一次以上的提交），如果流中存在UUID,则设定为版本库的 UUID。
- –use-pre-commit-hook
- 提交版本前调用 pre-commit 钩子
- –use-post-commit-hook
- 提交版本后调用 post-commit 钩子
- –parent-dir ARG
- 加载到版本库指定的目录中，缺省加载到根
- -q [--quiet]
- 在标准错误输出不显示进度 (仅错误)
- –help
- 查看 svnadmin load 命令的用法
示例：
$ svnadmin load –parent-dir new/subdir/for/project /opt/svn/svnroot/new_repos < dumpfile.txt
3. 裁减 ── svndumpfilter
- svndumpfilter
- 从标准输入读取版本库转存（导出）的格式文件，并导入到新版本库中。
用法：
svndumpfilter help [include] [exclude] svndumpfilter exclude PATH_PREFIX ... [OPTIONS ...] svndumpfilter include PATH_PREFIX ... [OPTIONS ...]
子命令：
- exclude
从标准输入中排除某个/某些路径下的内容，仅输出其它未指定路径下的内容。
- exclude
- include
- 仅从标准输入中包含某个/某些路径下的内容，其它未指定的路径下的内容被抛弃。
- help
查看帮助。后面提供 include 或者 exclude 参数，则输出 include 或 exclude 子命令的详细帮助。- help
参数：
- PATH_PREFIX …
- 路径前缀。可以是空格分隔的多个前缀，将对 svn 导出文件中属于该前缀之下路径的文件或者目录进行相应的处理（忽略或者包含）。前缀如果不包含”/”，将会自动添加一个”/”。
- –drop-empty-revs
- 删除因过滤而产生的空版本。
- –renumber-revs
- 过滤后重编余下的版本。
- –skip-missing-merge-sources
- 跳过缺少的合并源。
- –targets ARG
- 传递文件 ARG 的内容为额外的参数
- –preserve-revprops
- 不过滤版本属性。
- –quiet
- 不显示过滤的统计数据。
示例：
- 将 svn 的 dump 文件 inputfile 中出现的以 /trunk/module1 或者 /trunk/module2 为前缀的文件和路径忽略，其余文件和目录转存到文件 filteredfile。
$ svndumpfilter --drop-empty-revs --renumber-revs --skip-missing-merge-sources exclude /trunk/module1 /trunk/module2 < inputfile > filteredfile
4. 导入后目录降级
- 导入后目录降级
- 即导入到一个子目录中。如旧版本库 old_repos 中的 /trunk, /tags, /branches 等目录，导入到新库 new_repos 中的新路径为 repos1/trunk, repos1/tags, repos1/branches。
实现目录降级非常简单：
- 在新版本库中创建要导入到的子目录。如在新版本库 new_repos 中创建目录 repos1:
svn mkdir file:///opt/svn/svnroot/new_repos/repos1 -m "create new subdir for import"
- 在使用 svnadmin load 导入时，提供参数 –parent-dir DIR_NAME。如导入到新库的 repos1 目录：
svnadmin load --parent-dir repos1 /opt/svn/svnroot/new_repos < old_repos_dumpfile
5. 导入后目录升级
- 导入后目录升级
- 即 从旧版本的一个子目录的导出内容，导入到一个新版本库的根目录中。如旧版本库 old_repos 中的 repos1/trunk, repos1/tags, repos1/branches 等目录，导入到新库 new_repos 中的新路径为 trunk, tags, branches。
实现目录升级稍微复杂，需要对导出文件进行替换操作。
- 将旧版本的 repos1 模块下的文件（repos1/trunk, repos1/tags, repos1/branches）导出：
$ svnadmin dump /opt/svn/svnroot/old_repos | svndumpfilter include /repos1 --drop-empty-revs --renumber-revs > filteredfile 版本被重新编号如下: 10 => 7 9 => 6 8 => 5 7 => 4 6 => 3 5 => 2 4 => (丢弃) 3 => 1 2 => (丢弃) 1 => (丢弃) 0 => 0
- 将导出文件 filteredfile 中的路径 repos1 替换为空。
sed -e "s@^\(Node-path: \|Node-copyfrom-path: \)repos1/@\1@" filteredfile > filteredfile.fixed
- 用替换过的导出文件，导入到新库。如导入到 new_repos 版本库：
svnadmin load /opt/svn/svnroot/new_repos < filteredfile.fixed
- 删除新库中可能包含的 /repos1
如果要避免在新库中出现 /repos1 空目录，在导出旧版本库时使用 –revision X:Y 参数。X 是创建 /repos1 目录后的下一个版本，Y是版本库最新版本。
| 这篇文章由 蒋 鑫 于 2010年1月27日 - 09:51发表，分类于 Subversion, 版本控制。您可以通过 RSS 2.0 来订阅对该条目的回复。 也可以发表评论或引用到你的网站。 |
还没有引用。
Android repo 魔法
大约3天前 - 没有评论
Android 为企业提供一个新的市场，无论大企业，小企业都是处于同一个起跑线上。研究 Android 尤其是 Android 系统核心或者是驱动的开发，首先需要做的就是本地克隆建立一套 Android 版本库管理机制。
Android 使用 Git 作为代码管理工具，开发了 Gerrit 进行代码审核以便更好的对代码进行集中式管理，还开发了 Repo 命令行工具，对 Git 部分命令封装，将 百多个 Git 库有效的进行组织。要想克隆和管理这百多个 Git 库，还真不是一件简单的事情。
在研究 Repo 的过程中，发现很多文档在 Google Group 上，非“翻墙”不可看。非法的事情咱不干，直接阅读 repo 的代码吧。
创建本地 Android 版本库镜像的思路
如果了解了 Repo 的实现，参考 《Using Repo and Git》 , 建立一个本地的 android 版本库镜像还是不难的：
下载 repo bootstrap 脚本
$ curl http://android.git.kernel.org/repo >~/bin/repo
$ chmod a+x ~/bin/repo
$ export PATH=$PATH:~/bin
提供 –mirror 参数调用 repo 阅读全部内容 »
Repo——另一个Git协同模型
大约3天前 - 没有评论
Git 的神奇之处在于，你可以用很多不同的方式来使用它，而不像 Subversion，只有集中式一种方式。
最近又发现了一个 Git 新的协同模型 —— Repo，这个协同模型对于一个项目用到了多个Git版本库的协同开发非常有效。
实际上，这是上周在给一个团队做 “Git培训” 时，发现该团队在 Android 开发中，需要使用 Repo 这个工具来维护 Android 代码。于是花了些时间研究，补充了新的一章到讲义中…
Repo 是 Google Android 项目的附属工具，用于维护 Android 超级复杂的 Git 库（150多个独立的Git库）。虽然 repo 属于 android 项目，但 repo 本身可以独立使用，可以作为独立的工具，被任何项目使用。
用一句话概括 Repo： Repo 让分散的各自独立的 Git 版本库整合为一个整体。
不是有 git submodule 么？为什么还会出现一个 repo 呢？主要的原因，我认为有：
子模组不能指向Git库的某一分支，只是指向某个 commit
这对于项目发布没有问题，子模组指向 commit，即相当于固定于某个版本（里程碑）
但是对于开发非常不方便 。子模组固定于某个 commit，相当于处于 detached HEAD 状态，必须切换到分支才能更改。但是子模组对应于git库的哪一个分支，子模组的实现不能给出答案
主版本库和各个子版本库各自独立操作，不能整体的查看状态，查看differ
Repo 的实现很有趣，通过 repo 可以将本来各自独立的 Git 库在形式上整合为一个整体，可以用 repo 的命令进行整体操作。
通过一个 manifests git 阅读全部内容 »
Subversion管理后台增加对SVN容灾的支持
大约5天前 - 没有评论
群英汇Subversion版本控制系统提供的基本服务，实际上已经包含了简单的容灾实现：
在本机使用 gistore 进行数据备份
在备机上用 git pull 进行每日一次的数据同步
这个方法对于大多数公司，对于非核心数据的容灾备份已经足够，但是对于代码，不同的公司有着不同的敏感度，可能每日一次的备份就不合适了。
最近在给一个客户进行SVN版本控制系统的实施时，就碰到了SVN服务器间建立镜像和实时备份的需要
两个异地的开发团队，每个团队工作在不同的本地版本库，可能会参考（读取）异地不同版本库的内容
异地团队中间通过无线网桥互联，互联网桥的通讯质量易受到环境、气候的影响
如果两个异地的SVN服务器能够互做镜像，可以实现双机热备
一个团队可以在本地的主版本库中读写，一旦有数据写入本地版本库，就会同步到无线网桥另外一端的版本库。反之亦然。
由于本地还提供无线网桥另外一端版本库的镜像，因此访问远程版本库可以改用本地镜像进行访问，实现本地读取速度。
如果需要写入，配置 SVN反向代理，实现透明的远程写入。
Subversion可以使用 svnsync 这一工具实现版本库的远程镜像，但是如果使用手工配置，对于客户数量众多的版本库，难以维护。加之很多版本库本身很大，从头建立同步可能会非常缓慢。
我们通过在SVN管理后台增加了一对儿插件，实现了对SVN容灾（镜像）的图形化配置界面。
为同步用户建立用户帐号，并授权
在使用 svnsync 将本地版本库实时同步到远程版本库时，需要使用具有完全读写权限的帐号来完成对远程版本库的同步。
因此需要事先建立svn同步用户帐号，并在镜像的目标版本库对该帐号进行授权。
在用户管理平台，创建专门进行 svn 数据同步的用户帐号
不要将该用户加入任何用户组，即该用户禁止自行更改口令
因为该用户的口令更改，将破坏已经配置好的数据同步
使用SVN管理后台，对该用户授权，使其可以读写整个版本库（镜像的目标版本库）
镜像版本库的配置
为镜像版本库配置 ReadonlySvnMirror 插件，如下：
本例中，镜像SVN库的服务器地址为： http://svn2.moon.ossxp.com/svn/omed
该版本库只需要安装一个插件，即 ReadonlySvnMirror 插件
本例中，配置 Svnsync 管理员为 svnmirror
含义为只有用户 svnmirror 可以对该版本库进行提交，其它用户不能在该版本库中提交
源版本库的配置
为源版本库配置 SvnSyncMaster 插件
本例中，omed的主版本库地址为 http://svn.moon.ossxp.com/svn/omed，该版本库将向 http://svn2.moon.ossxp.com/svn/omed 发起实时的数据同步
本例中，发起同步的用户名为 svnmirror，该用户名和在svn2镜像服务器端的 ReadonlySvnMirror 插件配置的 svnsync 管理员用户名保持一致
用户口令是在用户管理平台为该用户(svnmirror)设置的口令，尽量选用长的口令
在“下游 SVN 镜像 URL”中输入镜像SVN版本库URL地址，每个一行。对于本例，输入地址：
http://svn2.moon.ossxp.com/svn/omed
镜像同步初始化
在SVN主版本库中安装 SvnSyncMaster 插件时，可能会遇到如下错误
403错误，无权访问版本库：可能是镜像服务器的版本库尚未对同步用户授权
403错误，无权访问版本库：可能是镜像服务器的版本库URL输入错误，错误的URL当然是没有授权的了
版本库尚未建立：如果镜像的目标版本库尚未建立，则不能在目标版本库记录同步信息也不能建立同步
版本库UUID不匹配：镜像初始化，会检查源版本库和目标版本库的UUID是否一致，如果不一致，可能会导致版本库同步的张冠李戴
证书不被信任或者证书签名者不被信任：换用 http 协议试试
其它
在配置相关插件之前，可以先通过拷贝方式将目标版本库复制到镜像服务器中
使用 scp 或者 rsync 的方式将主版本库复制到镜像服务器更直观，速度也更快
可以保证主版本库和镜像版本库的UUID保持一致
数据库复制完毕后，要修改镜像版本库的目录和文件的属主及权限。应该属于 www-data 用户
配置 SvnSyncMaster 插件，会自动根据当前镜像服务器端的版本号确定同步的进度，建立镜像关系
注意：不要在同步已经建立后再使用rsync。如果在镜像关系已经建立后，用rsync进行数据同步，会导致：
版本库插件配置被覆盖。因为版本库插件的配置位于版本库 conf/hooks.ini 文件中
版本库镜像信息被覆盖。因为版本库镜像信息保存在 rev0 的版本属性中
爱上Git——《Git培训讲义》摘录
大约2周前 - 没有评论
群英汇的开源版本控制系统服务和咨询主要是基于Subversion，群英汇的开源项目管理系统平台主要集成的也是Subversion。但是我们公司（群英汇）内部的开发一直在使用Git，所以实际上，我们在Git上也有着丰富的使用和管理经验。
最近一个客户选择了我们提供Git的培训和部署服务，于是从上周开始着手准备《Git培训讲义》。
这个客户是有着实际的需求，才不得不从 Subversion 迁移到 Git，虽然只是公司的部分项目组。
《Git培训讲义》中开头有一章，我给它命名为“爱上Git”，抓眼球是其次，主要是先让用户能够立刻“爱上Git”。
爱上Git(1): 原位版本库创建
需求：要对部署的文件进行原位修改，记录变更并以 patch 形式导入正式版本库
要是使用SVN 该怎么办呢？
$ svnadmin create /path/to/repos
$ svn checkout file:///path/to/repos
$ svn add *
$ svn commit
思考： 引入.svn 目录，在 Web 服务器上的风险…
Git 就简单多了:
git init
git add .
git commit
爱上Git(2): 重写提交说明
需求：提交说明忘了添加bugid, 或者bugid 写错了，需要重写 commit log
要是使用SVN 该怎么办呢？
管理员开放版本属性编辑权限
svn ps –revprop -r HEAD svn:log “new log message…”
警告：不要改错版本…
Git 就简单多了:
对于当前提交
git ci –amend
对于历史提交
git rebase -i <commit-id>^
提示：使用 reword 子命令
爱上Git(3): 撤销提交
需求：提交的数据包含一个不应该检入的 .zip 大文件，浪费空间和检出时间
要是使用SVN 该怎么办呢？
管理员重整版本库
svnadmin dump
svndumpfilter
svnadmin 阅读全部内容 »
pySvnManager 0.5 升级指引
大约3周前 - 没有评论
对于不能提供 SSH 远程登录服务器的用户，可以参照本文进行 pySvnManager 的升级。关于 pySvnManager 的新功能，参照：《pySvnManager新功能：LDAP用户同步》
升级的步骤简单的说就是：备份 -> 软件升级 -> 重启服务
数据备份
你可以备份 /opt/pysvnmanager 整个目录（主要是下面的 sites 目录）。
$ sudo cp -a /opt/pysvnmanager /opt/pysvnmanager.old
如果使用 gistore 备份，也可以执行命令：
$ sudo gistore commit-all -v
软件升级
首先更新 APT 源，以便 Debian/Ubuntu 能够感知上游软件的更新。
$ sudo aptitude update
升级 pysvnmanager
$ sudo aptitude install pysvnmanager
升级过程中 aptitude 命令可能会显示或者询问一些升级策略。例如：提示安装 pysvnmanager-deploy-virt 包，并卸载原来安装的 pysvnmanager-deploy-sys 包。这是因为：
pysvnmanger 软件包实际上包含了下列组件包：
pysvnmanager ：不包含实际数据，仅用于确立包的依赖关系。必须安装 pysvnmanager-common 包，以及pysvnmanager-deploy-sys 或者 pysvnmanager-deploy-virt 包中的任何一个。
pysvnmanager-common ： 主要的源代码和执行脚本都在这个包中。
pysvnmanager-deploy-sys ： 使用系统提供的第三方软件包，使得 阅读全部内容 »
pySvnManager 新功能：LDAP用户同步
大约3周前 - 没有评论
pySvnManager 升级到 0.5 版本，引入了数据库支持，数据库主要用于保存和 LDAP 用户帐号同步的用户帐号信息。
数据库采用 sqlite 数据库（如果需要也可以使用其它类型数据库），无须手动创建数据库，在 pySvnManager 运行时，会根据需要自动创建数据库。
在没有使用 LDAP 用户信息之前，pySvnManager 是读取 SVN 授权文件，从该授权文件中获取用户名单并显示。
可以看出这种实现的问题是：
在权限检查的用户列表中，只能看到用户登录ID，而看不到用户 ID 对应的用户名
显示的用户帐号很少（只有在 SVN 授权文件中引用的用户帐号才能显示）
为新用户授权，如果用户不在授权文件中，需要手工输入用户名，容易出错。
pySvnManager 0.5 增加了内置数据库和LDAP用户同步功能之后，再看 pySvnManager 中显示的用户列表：
你会发现新版本的用户列表（已经完成和LDAP同步）：
除了显示用户ID外，还显示用户名
显示的用户多了很多，除了在 SVN 授权文件中引用到的用户外，LDAP 中授权的 SVN 用户也显示出来了
在为新用户授权时，不必手工输入用户，只需要进行一次 LDAP 用户同步，用户帐号信息自动显示出来。
那么如何进行LADP 同步呢？
我们把 LDAP 用户同步的按钮放在“角色管理”界面，只要点击其中的“和LDAP用户同步”图标按钮，自动完成同步。
其它改进还包括：更好的 IE6 支持，UI 的重新设计等等。我们会陆续协助客户完成软件升级。
用户手册也已经更新，参见： 《pySvnManager 用户手册》
关于如何升级到新版本的 pySvnManager，参照《pySvnManager 0.5 升级指引》
Git 服务器软件 gitosis 的改进
大约1月前 - 没有评论
群英汇内部的 Git 服务器使用 gitosis 软件架设，能够实现针对版本库的授权，以及基于公钥的安全的无口令的版本库访问。
在 Gitosis 的使用过程中，我们根据需要对其进行了改进，以满足我们对授权和版本库管理上的需求：
增加了管理员角色，只有管理员才能够创建版本库
原来的实现只有 readonly 和 writable 两种权限，其中 writable 可以创建版本库。
我们权限分为三级：read/write/admin。拥有管理员(admin)权限，可以创建版本库，并自动具有读(read)写(write)权限
拥有写(write)权限也包含读(read)的权限
如果没有设置权限，禁止范围版本库
版本库匹配支持通配符，这样在授权的时候，可以用通配符为某个目录下的所有代码库授权
原有的实现，在配置文件中必须写入完整的版本库名称（路径）
当我们增加了管理员的概念后，增加通配符，就可以为特定的命名空间进行授权，而无须因为某个管理员要建库，还要修改授权文件
有了通配符后，读写权限的设置也更为简单。
通配符支持？，* 和 **。问号匹配一个字符，* 匹配任意字符（路径/字符除外），两个星号匹配包括路径分割符在内所有字符
增加了版本库路径映射的可用性。版本库路径映射在代码库重构中非常有用
增加了正则表达式匹配路径和替换映射
在权限检查的路径命中之后也检查路径映射，可以减轻错误配置的可能性
创建版本库只有写操作才进行，读操作不创建版本库
原来的实现支持即时创建版本库，在读取一个不存在的版本库时自动创建
读操作创建库，这会导致很多因为版本库克隆时路径输入错误导致错误建库
我们更改后，只允许在写版本库时并且具有 admin 权限才初始化新的代码库
版本库名称中允许出现中文（UTF-8）
基本上版本库命名都用英文字符，不过有个客户提出来支持中文版本库，我们就添加了这个支持
下面，拿一个配置文件来说明：
1 [gitosis]
2 repositories = /gitroot
3 #loglevel=DEBUG
4 gitweb = yes
5 daemon = no
[gitosis] 小节配置的是全局参数，可以在各个版本库自定义的小节中对其覆盖
第二行设置版本库缺省的根目录，git 版本库一般都会建在这个目录的下面
gitweb 和 daemon 用于设置和 gitweb 和 gitdaemon 的整合
7 [group gitosis-admin]
8 write 阅读全部内容 »
pySvnManager 升级
大约2月前 - 2条评论
pySvnManager 升级为 0.4.1，并撰写了用户手册和开发者手册。相关的更新：
重新设计的用户界面，更加人性化。不知道我当初为什么手那么懒，呵呵。
能够发现 svn 授权文件手动更改，并在警告信息中提供保存的链接
能够运行在最新的 Pylons 1.0 框架中，并且支持 virtualenv，可以彻底解决 python 包依赖问题
pySvnManager 用户手册，提供详细的安装以及操作指南
pySvnManager 开发者文档，提供 pySvnManager 软件架构的详细解说，供爱好者改进时参考
Python setuptools hack: get revision from git-svn
大约3月前 - 没有评论
Python egg 打包有赖于 setuptools。setuptools 有一个功能很有意思，就是准备打包的软件如果使用了 subversion 版本控制系统，会自动将当前SVN的提交版本号附加在生成的软件包文件名中。
例如：pySvnManager-0.4.1dev-r131.tar.gz 中的 r131 含义就是从 svn 的 131 提交版本创建的源码包。
但是如果使用 git-svn来检出 svn 版本库，再运行打包命令 “python setup.py sdist”，就失去了这个帅呆了的功能。怎么办呢？
Hack 一下 setuptools 呗，之前就干过。
曾经的 Hack： setuptools 不支持新版本的 SVN
之前就遇到过，当使用最新的 SVN 客户端时，setuptools 用于从 .svn/entries 文件解析出当前提交版本时，因不能识别 SVN 版本而失败。
从下面的代码可以看到，当 SVN 新版本推出后，setuptools 需要进行相应的更新，这肯定要有一个时间差。
f = open(os.path.join(base,’.svn’,'entries’))
data = f.read()
f.close()
if data.startswith(‘10′) or data.startswith(‘9′) or data.startswith(‘8′):
SVN 1.6 的 .svn/entries 文件头一行的版本标识是 10, 阅读全部内容 »
Subversion 用户眼中的 Git (13): Git 成为 SVN 的伙伴？
大约3月前 - 没有评论
很多公司不能代码开源，甚至也不能实现内部的代码开源，这相当大的原因是政治原因，而非技术原因。
那么当工作在 Subversion 的版本库下，是不是就和 Git 绝缘了呢？
非也，答案就是 Git-svn。
Why Git， not others
为什么 Git 可以成为 SVN 的好伙伴，而不是其它的分布式版本控制系统呢？
答案就在于分支。
Git 相比其它分布式版本控制系统（Hg），虽然从使用习惯上距离 SVN 最远，但实际上却是最近的。这是因为 Git 有着完整的分支管理机制（比 SVN 还要优秀），因此可以完整的实现 SVN 库到 Git 库的迁移。
另外一个专为 SVN 而生的分布式版本控制系统 SVK 也是一个选择，但是好像已经停止维护了。
Git-svn
GIT-SVN 是一个 Perl 开发的 Git 插件。因为是 Perl 语言开发，因此还依赖 “Perl bindings for Subversion”。
GIT-SVN 的使用这里不多提，只是介绍一下可以实现的功能：
缺省可以克隆标准的 SVN 库，即 trunk/branches/tags 布局的 SVN 库
很多公司的 SVN 库，没有设置 branches, tags 目录，是缺乏管理的表现
对于非标准布局的 SVN 库，可以通过相应参数，实现分支和里程碑的对应
对于非常庞大的 SVN 库，也可以只克隆最近的提交，而不必克隆整个历史
可以随时从 阅读全部内容 »
大约7月前
有客户说：“参照博客的方法，在向新建立的版本库导入时，报错：没有找到文件…”
和我在博客中的例子不一样的是，我的例子中 svndumpfilter 包含是整个 branches 目录（是一级目录），而客户操作的是二级目录。
我的例子中导出文件是一级目录，可以直接导入，因为根 ／ 已经存在。
客户的例子是二级目录，不存在 branches，在创建空的版本库后，需要创建一级子目录然后再导入。
即创建完毕空版本库（svnadmin create test）后，执行
svn mkdir file:///path/to/repos/branches
诸如此类。。。
如果在导入时，提示已经存在了某个目录或文件，则需要执行
svn rm file:///path/to/repos/path/to/conflict
删除已经存在的目录或者文件。
大约7月前
客户问题：
> 在load的时候还是报错： svnadmin: 转存流在“Out of memory – term”包含错误头部（没有“:”）
看来是导出文件太大了，导致内存不足。
解决方法是：
* 在用 svnadmin dump 的时候，使用 -r X:Y 参数，分批导出
* 例如第一次先导出 1000 个提交，第二次在导出 1000 个提交
* 注意：在第二次之后的导出时，要使用 –incremental 增量导出
还有，在执行命令前，最好先设定一下环境变量：
这样，错误输出将显示为英文，而不是翻译的磕磕巴巴的中文。
大约7月前
客户又有问题反馈，因为比较复杂，我就另写了一个博文：
版本库整理的内存溢出问题
大约6月前
客户需要导出两个分支，但是不想导出 /trunk，问我可以不可以。
下面是我的回答：
首先要说，是可以实现的。可以实现只包含 branches 下分支的历史，从 trunk
拷贝之前的历史全部丢弃，也可以在重建的版本库中根本就不要 /trunk 。
但是这么做的问题是，带来数据冗余，两个分支的初始内容都是来自于 /trunk，
但是这回变成了各自独立一份。
下面是示例操作:
因为 branch_2 是从 trunk 建立的，如果过滤掉 trunk, 也要过滤掉 branch_2
因为 branch_1 将从上一步的导出文件来创建
$ svnadmin load new < r3-7-filtered.txt <<< 开始新的事务，基于原始版本 3 * 正在增加路径: branches ...完成。 * 正在增加路径: branches/branch_1 ...完成。 * 正在增加路径: branches/branch_1/readme ...完成。 ------- 提交新版本 1 (从原始版本 3 装载) >>> < << 开始新的事务，基于原始版本 4 * 正在增加路径: branches/branch_1/file1 ...完成。 ------- 提交新版本 2 (从原始版本 4 装载) >>> $ svnadmin load new < r5-7-filtered-no-create-branches.txt <<< 开始新的事务，基于原始版本 5 * 正在增加路径: branches/branch_2 ...完成。 * 正在增加路径: branches/branch_2/readme ...完成。 ------- 提交新版本 3 (从原始版本 5 装载) >>> < << 开始新的事务，基于原始版本 6 * 正在增加路径: branches/branch_2/file2 ...完成。 ------- 提交新版本 4 (从原始版本 6 装载) >>> $ svn log -v file:///home/jiangxin/tmp/svn/new ------------------------------------------------------------------------ r4 | jiangxin | 2010-02-23 13:23:16 +0800 (二, 2010-02-23) | 1 行 改变的路径: A /branches/branch_2/file2 add file2 in branch_2 ------------------------------------------------------------------------ r3 | jiangxin | 2010-02-23 13:22:19 +0800 (二, 2010-02-23) | 1 行 改变的路径: A /branches/branch_2 A /branches/branch_2/readme create branches/branch_2 from trunk r4 ------------------------------------------------------------------------ r2 | jiangxin | 2010-02-23 13:22:46 +0800 (二, 2010-02-23) | 1 行 改变的路径: A /branches/branch_1/file1 add file1 in branch_1 ------------------------------------------------------------------------ r1 | jiangxin | 2010-02-23 13:21:49 +0800 (二, 2010-02-23) | 1 行 改变的路径: A /branches A /branches/branch_1 A /branches/branch_1/readme create branches/branch_1 from trunk r2 ------------------------------------------------------------------------