分布式配置管理

未来的潮流?!

ZQ-DSCm Vs

集中 vs 分布

DSCM, Distributed Software Configuration Management ?! 

理论分析:

模式对比

集中式CM

分布式CM

cscm.gif

dscm.gif

现行自由SCM使用对比

现行有数十种自由版本管理系统!下表仅选取有成功大型项目使用的版本系统进行简要对比

系统名

短名

实际项目

备注

集中式SCM

Concurrent Versions System

cvs

FreeBSD,OpenOffice.org ...

最老牌的自由版本管理系统,虽然有先天缺陷,但是非常成熟

Subvertion

svn

Apache.org ;Python;GCC;KDE;Gnome; Zope,Plone;重要用户列表...

比CVS更加完备的实现 rcs 体系的新兴版本系统,有丰富的软件支持体系

分布式SCM

SVK

svk

RoR;Wine; 用户列表

Perl脚本集合,将SVN扩展成分布式的系统

Mecurial

Hg

Mozilla;Open Solaris;Xen;wget;ZFS 用户列表...

Python实现

Bazaar-NG

Bzr

Ubuntu; Launchpad;moin-1.6;Drupal;用户列表...

Python实现

Arch

~

Debian;moinmoin..用户列表

Arch 是分散 SCM 的规范,它提供许多不同的实现,包括 ArX、Bazaar(baz)、GNU arch 和 Larch

git

git

linux-2.6

C开发; 没有完善的Win32 GUI工具

Monotone

mtn

Pidgin(Gaim)

Lua开发; 没有完善的Win32 GUI工具

Darcs

~

DuKuWiki;Psi ;prototype; 用户列表...

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 就是汞嘛 :D

下面再让我们看看几个候选人,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 环境下苟延残喘的程序员来说,有个好消息。那就是托开源的福,可爱的小乌龟无处不在。

不过就我的历史经验,只有 TortoiseSVN 是正宗乌龟,最好用。不用对其它版本乌龟的操作手感抱太大希望。

Zq's回复

说到困惑: 1. 我们禁止提交不能编译通过的代码

  • ~ 使用 tangle 目录,收集不成熟的

2. 有些模块由两个人合作~通过代码仓库中转

  • ~ 这是必然的,协同过程也应该记录

3. 代码被用笔记本带回家,结果在家完成的部分无处可以提交

  • ~ 工作不应该带回家(而且分布式后,公司的核心代码如何保卫?)

4. 有 bug 没有修改完,而不敢提交

  • ~ 心理障碍和CM没有关系
  • 俺最不敢推广DCM 的原因只有一点:
    • 复杂! 当前这么简单的检入/出,多数开发成员都无法理解和作到有效,
    • 再玩分布式的?乱是唯一的结果了 ;)

当然精英团队,该上赶紧上!

实际体验

Hg ~ 水银般的流畅

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下)

附送一下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]

DistributedScm (last edited 2009-12-25 07:14:04 by localhost)