Contents
分布式配置管理
未来的潮流？！
- ZQ-DSCm Vs
集中 vs 分布
DSCM, Distributed Software Configuration Management ?!
理论分析:
模式对比
集中式CM |
分布式CM |
|
|
|
|
现行自由SCM使用对比
现行有数十种自由版本管理系统!下表仅选取有成功大型项目使用的版本系统进行简要对比
系统名 |
短名 |
实际项目 |
备注 |
集中式SCM |
|||
Concurrent Versions System |
cvs |
最老牌的自由版本管理系统,虽然有先天缺陷,但是非常成熟 |
|
Subvertion |
svn |
比CVS更加完备的实现 rcs 体系的新兴版本系统,有丰富的软件支持体系 |
|
分布式SCM |
|||
SVK |
svk |
Perl脚本集合,将SVN扩展成分布式的系统 |
|
Mecurial |
Hg |
Python实现 |
|
Bazaar-NG |
Bzr |
Python实现 |
|
Arch |
~ |
Arch 是分散 SCM 的规范，它提供许多不同的实现，包括 ArX、Bazaar(baz)、GNU arch 和 Larch |
|
git |
git |
C开发; 没有完善的Win32 GUI工具 |
|
Monotone |
mtn |
Pidgin(Gaim) |
Lua开发; 没有完善的Win32 GUI工具 |
Darcs |
~ |
Haskell 实现的轻量分布式版本系统 |
|
实用分析
- 分布式是趋势
- 集中是工业标准
- 在好处没有抵过复杂前,应当缓行
相关言论
云风的Blog.分布式的版本控制工具
我最早接触的 SCM 工具是 vss ，但是没用几天（换工作到网易后）就迁移到了 cvs 。我自己大约用了一年后，公司集体从 cvs 迁移到了 svn 。领导这次大迁徙的大大说， svn 是一个更好的 cvs （确实是这样吗？据说有争议，但至少我感觉在多文件版本控制上 svn 比 cvs 方便）。
前几年，有人跟我争论过到底 vss 的加锁模式好，还是 cvs 的合并模式好。我觉得答案是不言而喻的，懒得争论。虽然在某些特殊环境上，我们偶尔需要加锁模式协同工作，但对于程序员的协作来说，无疑我们需要并行的工作。
我们在若干年前曾经淘汰过一次加锁的协作编码方式，而到了今天，是时候再做一些改变了。或许，分布式的版本控制工具才是未来的发展方向。我想，总有一天，cvs/svn 这类集中式版本控制工具会被淘汰掉的。
说说我的困扰吧，可能很多开发小组也遇到过。
- 我们禁止提交不能编译通过的代码，尽量不提交不能测试通过的代码。结果，对于很复杂的模块，有人几乎一个月都没提交过一次。他总是觉得程序还不太成熟，但几经修改的代码其实从来没有作版本控制。
- 有些模块由两个人合作编写，关系非常紧凑。有时候需要在两人之间交换一些代码，为了方便，大家通过代码仓库中转，结果在仓库中留下许多未完成的版本。
- 代码被用笔记本带回家，结果在家完成的部分无处可以提交。（为了安全，我们的代码仓库不能从外网访问）
- 某人写了一个模块，总是有 bug 没有修改完，而不敢提交。这个时候，另一个人希望协助他找问题，却没有合适的途径 share 那段完成了一半的模块。跑过去 XP 一下么？天哪，为什么我们这里每个人用的编辑器都不一样，还都爱用些特别个性的配色方案呢？
我们尝试过一些 work around 的解决方法，比如在本地自己创建仓库。托 TortoiseSVN 的福，这件事在 Windows 下做起来还是很简单的。可终归是多个仓库的管理，用的人始终感觉麻烦，而没有贯彻下去。
今天有同事问我，分布式版本控制工具到底跟我们现在在用的系统有什么区别。我想了一下回答说，它的本质就是在原有工具的基础上增加了一种仓库合并的功能。（哈，我接触这类东西时间不长，大家就当我胡说）
集中式版本控制工具，总要求你有一个中心服务器，提供一个项目仓库。每个人都必须严格保持跟仓库的内容一致。当项目大于等于 2 人时，往往都会指定一些规则，比如不要提交写了一半的代码到仓库去等等。结果，这些规则导致了上面我提到的问题。
即使是一个人自己用，有时候也会碰到问题。有一次我回到家，看到老爸（一个老程序员）在家做一个自己的小东西。因为我们家有两台电脑，我看见两台机 器上有若干份不同的版本，我便推荐他用 svn 。因为两台机器都不是 24H 开机，我便选择了在 U 盘上创建仓库。可以设想的到，两台机器的 U 盘插入后盘符是不同的，这可真是一场灾难啊。
其实大多数情况下，我们要的仅仅是 版本管理 ，并不要求通过这类工具协同很多人修改同一份代码。在我们公司，修改别人的代码是要通知文件创建人的。大家都尽量在自己的工作目录下写东西。我并不要求分 布式的版本控制工具帮我解决开发人员分布在不同地方的问题，我需要的仅仅是可以更方便的创建私人（或小团体）的分支，可以局部的提交的问题。这些，只需要 一个仓库合并的特性就做到了。
我比较孤陋寡闻，知道有分布式版本控制工具是从 git 发布的消息开始的。有 Linus 的鼎鼎大名在那，应该是个好东西。我想还会有一些跟我一样，一进入项目开发就两耳不闻窗外事的朋友，不知道 git 是何物的话，不妨看看 Git 中文教程 。
可惜的是，git 对 Windows 支持的并不好。我们至少还有一半的项目跑在 Windows 下，开发人员则超过一半在用 windows 平台。听说其原因是 git 非常依赖文件系统的一些特性，这些在 Linux 下表现的很好，而 Windows 下特别糟糕。不管具体原因是这个还是别的，我对在公司推广 git 没有多少信心。
另一个选择是 Monotone ，但听说跟 git 有同样的问题（对 windows 的支持问题）。毕竟 git 本身就受了 monotone 的很大影响吧（我猜的）。有趣的是，和 Git 一样 Monotone 也是用 C 写的。当然这句话其实应该倒过来说，因为 Monotone 是从 2003 年开始的，比 Git 早多了。
关于 Git 和 monostone 对 windows 支持不太好的说法，可以参考这一篇： Mozilla: Version Control System Shootout Redux Redux ，Mozilla 的大大这样评价：Git is inappropriate for cross-platform projects due to its UNIX-centric nature; same goes for Monotone.
嗯，既然 Mercurial 是 (Mozilla 的) current favorite (but not the winner) ，我们也可以关注一下。说起来，Mercurial 的命令名很有趣，是 hg 。我花了几秒钟才反应过来，Hg 就是汞嘛 
。
下面再让我们看看几个候选人，Bazaar 的网站上有它和其它几种工具的比较。虽然有人说它性能不行，但我想那是针对 Mozllia 这种超级项目说的，我想对我们这样的小东西不会有什么影响。别的方面看起来很不错哟。尤其是它宣称的智能 rename ，真是太有爱了。
svn 下给目录 rename 绝对是场灾难。如果你不小心没有直接去仓库中 rename ，那么就意味着目录下所有文件的 del / add 。而即使你在仓库上直接操作，所有 client 都会大量的做 del / add 操作。每当这个时候，我都超心痛我的硬盘。
darcs 看起来也不错，我对 Haskell 本身就有莫名的好感，用 Haskell 写出来的软件对我就意味着稳定。虽然我自己不怎么玩 Haskell 也不太用 Python ，但是若让我花时间选一门语言玩的话，我会优先试试 Haskell 的。
作为 svn 的老用户，或许应该多关注一下 svk ，它在 svn 的基础上增加了一些分布式管理的东西。但是我不太喜欢这种补丁式的解决方案，因为设计总会随着需求而改变。若是背上太多历史包袱会让我有些不详的预感。
最后可以看看 GNU Arch 。我浏览了 arch 的 wiki 中 WhyArch 这一页，吸引我的是最后两条：
- Arch is lightweight
- Arch has a clean and transparent design
不过从 google 搜索结果来看，我没觉得 GNU Arch 是个有前途的项目（相比前面几个而言）。
最后，对于我这样依然有部分时间在 Windows 环境下苟延残喘的程序员来说，有个好消息。那就是托开源的福，可爱的小乌龟无处不在。
Mercurial 的乌龟版：TortoiseHg
Bazaar 的乌龟版： TortoiseBZR
Darcs 的乌龟版： TortoiseDarcs
不过就我的历史经验，只有 TortoiseSVN 是正宗乌龟，最好用。不用对其它版本乌龟的操作手感抱太大希望。
Zq's回复
说到困惑: 1. 我们禁止提交不能编译通过的代码
- ~ 使用 tangle 目录，收集不成熟的
2. 有些模块由两个人合作~通过代码仓库中转
- ~ 这是必然的，协同过程也应该记录
3. 代码被用笔记本带回家，结果在家完成的部分无处可以提交
- ~ 工作不应该带回家(而且分布式后，公司的核心代码如何保卫?)
4. 有 bug 没有修改完，而不敢提交
- ~ 心理障碍和CM没有关系
- 俺最不敢推广DCM 的原因只有一点:
- 复杂！ 当前这么简单的检入／出，多数开发成员都无法理解和作到有效，
再玩分布式的？乱是唯一的结果了
当然精英团队，该上赶紧上！
实际体验
Hg ~ 水银般的流畅
MercurialNote ~ Mercurial 学习笔记
Hg 快速手册
刘鑫-Hg vs Bzr
Samuel Chi bzr和hg的初体验(WinXP)
Samuel Chi <[email protected]> reply-to [email protected] to "python-cn:CPyUG" <[email protected]> date Sun, Jul 20, 2008 at 02:42 subject [CPyUG:59750] Bazaar和Mercurial的初次体验(WinXP下)
- 安装: 都很容易,一个安装文件搞定
- 乌龟扩展: 乌龟hg安装更傻瓜,功能更强大,可是不太稳定;乌龟bzr安装麻烦,功能也少
- 使用: 基本功能都差不多,hg强在有统一配置,push/pull的操作可以简化--这个很方便,而且还有传说中的打包功能;
- 远程仓库:
- bzr更简单,服务器上基本不要配置太多东西
- ssh方式在windows下也只要装一个openssh for windows就ok了,缺点是路由器的端口转发不知道怎么会对sftp无效(我改成其他端口比如22222都不行,很想知道出错原因)
- http的配置也很简单,缺点就是无法push(真希望能有人来指出偶的观点是错误的)
- hg号称能支持多种方式,可是我忙了一天除了自带的hg serve,其他的都没测试成功(连apache的支持都没搞定,极度郁闷)
附送一下bzr的apache配置,希望能对大家有用:
Alias /bzr "f:/bzr/"
<Directory "f:/bzr/">
Options FollowSymLinks
AllowOverride FileInfo Indexes Limit
Order allow,deny
Allow from all
Require valid-user
AuthType Basic
AuthName "Bazaar Repository"
AuthUserFile f:/bzr/authlist
</Directory>
就不需要像svn一样,每一个仓库都要写一个<Location ....>
配置hg出错的apache日志如下:
// access.log 127.0.0.1 - princeofdatamining [20/Jul/2008:01:43:42 +0800] "GET /hg/ HTTP/1.1" 500 650 // error.log [Sun Jul 20 01:43:42 2008] [error] [client 127.0.0.1] (OS 5)拒绝访问。 : couldn't create child process: 720005: index.cgi [Sun Jul 20 01:43:42 2008] [error] [client 127.0.0.1] (OS 5)拒绝访问。 : couldn't spawn child process: F:/Hg/index.cgi
热切期盼有人来分享一下mercurial的apache配置心得....
反馈
创建 by -- ZoomQuiet [2008-03-26 02:20:28]
