##language:zh #pragma section-numbers off ##含有章节索引导航的 ZPyUG 文章通用模板 <> ## 默许导航,请保留 <> ##startInc = 集中 vs 分布 = `DSCM, Distributed Software Configuration Management ?! ` '''理论分析:''' * '''[[http://blog.ianbicking.org/distributed-vs-centralized-scm.html|distributed-vs-centralized-scm]]''' * [[http://pluskid.lifegoo.com/?p=24|git and subversion]] * [[http://www.dwheeler.com/essays/scm.html|FLOSS SCM系统对比]] * [[http://www.gnuarch.org/gnuarchwiki/SubVersionAndCvsComparison|SVN,CVS,Aegis,SVK,Arch 对比]] * [[http://weblogs.mozillazine.org/preed/2007/04/version_control_system_shootou_1.html|Mozilla 选择SCM过程戏说]] == 模式对比 == || 集中式CM || 分布式CM || ||<^> {{attachment:cscm.gif}} ||<^> {{attachment:dscm.gif}}|| ||<^> <> ||<^> <>|| == 现行自由SCM使用对比 == '''现行有[[http://monotone.ca/others.html|数十种自由版本管理系统]]!'''下表仅选取有成功大型项目使用的版本系统进行简要对比 || '''系统名''' || '''短名''' || `实际项目` || 备注 || ||||||||<#FFFFA0> 集中式SCM || || Concurrent Versions System || cvs || [[http://cvsweb.freebsd.org/|FreeBSD]],[[http://download.openoffice.org/2.0.0/source.html|OpenOffice.org]] ... || 最老牌的自由版本管理系统,虽然有先天缺陷,但是非常成熟 || || Subvertion || svn ||'''[[http://www.apache.org/dev/version-control.html|Apache.org]]''' ;[[http://svn.python.org/projects/python/|Python]];[[http://gcc.gnu.org/|GCC]];'''[[http://www.kde.org/|KDE]]''';'''[[http://svn.gnome.org/|Gnome]]'''; [[http://www.zope.org/|Zope]],[[http://dev.plone.org/plone|Plone]];[[http://subversion.tigris.org/testimonials.html|重要用户列表]]... || [[http://www.ibm.com/developerworks/cn/java/j-subversion/index.html|比CVS更加完备]]的实现 rcs 体系的新兴版本系统,有丰富的软件支持体系 || ||||||||<#FFFFA0> 分布式SCM || || SVK || svk || [[http://www.rubyonrails.org/|RoR]];[[http://www.winehq.com/|Wine]]; [[http://svk.elixus.org/view/ProjectsUsingSVK|用户列表]] || Perl脚本集合,将SVN扩展成分布式的系统 || || Mecurial || Hg ||'''[[http://hg.mozilla.org/|Mozilla]]''';[[http://opensolaris.org/|Open Solaris]];[[http://xenbits.xensource.com/|Xen]];[[http://hg.addictivecode.org/|wget]];[[http://www.wizy.org/mercurial/|ZFS]] [[http://www.selenic.com/mercurial/wiki/index.cgi/ProjectsUsingMercurial|用户列表]]... || Python实现 || || Bazaar-NG || Bzr ||'''[[https://launchpad.net/ubuntu|Ubuntu]]'''; [[http://launchpad.net/|Launchpad]];[[http://hg.moinmo.in/|moin-1.6]];[[http://drupal.org/|Drupal]];[[http://bazaar-vcs.org/BzrGlossary|用户列表]]... || Python实现 || || Arch || ~ || '''[[http://arch.debian.org/|Debian]]''';[[http://arch.thinkmo.de/2003-archives|moinmoin]]..[[http://www.gnuarch.org/gnuarchwiki/ArchPropaganda|用户列表]] || Arch 是分散 SCM 的规范，它提供许多不同的实现，包括 ArX、Bazaar(baz)、GNU arch 和 Larch || || git || git || [[http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary|linux-2.6]] || C开发; 没有完善的Win32 GUI工具 || || Monotone || mtn || Pidgin(Gaim) || Lua开发; 没有完善的Win32 GUI工具 || || Darcs || ~ ||[[http://wiki.splitbrain.org/wiki:darcs|DuKuWiki]];[[http://psi-im.org/|Psi]] ;[[http://prototype.conio.net/|prototype]]; [[http://wiki.darcs.net/DarcsWiki/ProjectsUsingDarcs|用户列表]]... || Haskell 实现的轻量分布式版本系统 || == 实用分析 == * 分布式是趋势 * 集中是工业标准 * 在好处没有抵过复杂前,应当缓行 = 相关言论 = == 云风的Blog.分布式的版本控制工具 == [[http://blog.codingnow.com/2008/01/distributed_version_control.html|原文链接]] 我最早接触的 SCM 工具是 vss ，但是没用几天（换工作到网易后）就迁移到了 cvs 。我自己大约用了一年后，公司集体从 cvs 迁移到了 svn 。领导这次大迁徙的大大说， svn 是一个更好的 cvs （确实是这样吗？据说有争议，但至少我感觉在多文件版本控制上 svn 比 cvs 方便）。 前几年，有人跟我争论过到底 vss 的加锁模式好，还是 cvs 的合并模式好。我觉得答案是不言而喻的，懒得争论。虽然在某些特殊环境上，我们偶尔需要加锁模式协同工作，但对于程序员的协作来说，无疑我们需要并行的工作。 我们在若干年前曾经淘汰过一次加锁的协作编码方式，而到了今天，是时候再做一些改变了。或许，分布式的版本控制工具才是未来的发展方向。我想，总有一天，cvs/svn 这类集中式版本控制工具会被淘汰掉的。 说说我的困扰吧，可能很多开发小组也遇到过。 1. 我们禁止提交不能编译通过的代码，尽量不提交不能测试通过的代码。结果，对于很复杂的模块，有人几乎一个月都没提交过一次。他总是觉得程序还不太成熟，但几经修改的代码其实从来没有作版本控制。 2. 有些模块由两个人合作编写，关系非常紧凑。有时候需要在两人之间交换一些代码，为了方便，大家通过代码仓库中转，结果在仓库中留下许多未完成的版本。 3. 代码被用笔记本带回家，结果在家完成的部分无处可以提交。（为了安全，我们的代码仓库不能从外网访问） 4. 某人写了一个模块，总是有 bug 没有修改完，而不敢提交。这个时候，另一个人希望协助他找问题，却没有合适的途径 share 那段完成了一半的模块。跑过去 XP 一下么？天哪，为什么我们这里每个人用的编辑器都不一样，还都爱用些特别个性的配色方案呢？ 我们尝试过一些 work around 的解决方法，比如在本地自己创建仓库。托 [[http://tortoisesvn.tigris.org/|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 这一页，吸引我的是最后两条： 1. Arch is lightweight 2. Arch has a clean and transparent design 不过从 google 搜索结果来看，我没觉得 GNU Arch 是个有前途的项目（相比前面几个而言）。 最后，对于我这样依然有部分时间在 Windows 环境下苟延残喘的程序员来说，有个好消息。那就是托开源的福，可爱的小乌龟无处不在。 1. Mercurial 的乌龟版：[[http://tortoisehg.sourceforge.net/|TortoiseHg]] 2. Bazaar 的乌龟版： [[http://bazaar-vcs.org/TortoiseBzr|TortoiseBZR]] 3. Darcs 的乌龟版： [[http://tortoisedarcs.sourceforge.net/|TortoiseDarcs]] 不过就我的历史经验，只有 [[http://tortoisesvn.tigris.org/|TortoiseSVN]] 是正宗乌龟，最好用。不用对其它版本乌龟的操作手感抱太大希望。 === Zq's回复 === 说到困惑: 1. 我们禁止提交不能编译通过的代码 * ~ 使用 tangle 目录，收集不成熟的 2. 有些模块由两个人合作~通过代码仓库中转 * ~ 这是必然的，协同过程也应该记录 3. 代码被用笔记本带回家，结果在家完成的部分无处可以提交 * ~ 工作不应该带回家(而且分布式后，公司的核心代码如何保卫?) 4. 有 bug 没有修改完，而不敢提交 * ~ 心理障碍和CM没有关系 * 俺最不敢推广DCM 的原因只有一点: * 复杂！ 当前这么简单的检入／出，多数开发成员都无法理解和作到有效， * 再玩分布式的？乱是唯一的结果了 ;) 当然精英团队，该上赶紧上！ ##endInc ---- '''反馈''' 创建 by -- ZoomQuiet [<>]