Monthly Archives: June 2008

最初是从cyfdecyf的文章认识mercurial的,后来用netbeans开发rails,当时netbeans 6.0还没正式发布,我在用netbeans 6.0测试版,发现竟然有mercurial插件,而且更新相当频繁,于是也对mercurial颇有好感,到后来mercurial插件纳入netbeans正式发布包里面,之后netbeans宣布从cvs转到mercurial,这一切都很自然发生了.mercurial 1.0正式发布,而且有netbeans插件,还有TortoiseHg这个类似TortoiseSVN的windows工具,再加上指令并不多(十条指令左右,相比git的几十条指令),而且你还可以在dreamhost上搭建你的中央源,mercurail始终是新手和小项目的首选

mercurail和git是一个很自由的版本管理软件,我们随时可以在自己的机器上任意一个目录启用版本管理,不需要任何服务器.但是,当我们需要跟别人协作的时候,应该怎么处理呢.我们可以N个人之间互相乱pull来push去,但是这样的网状结构并不方便管理,非常容易混乱,一般来说,我们会指定一个中央源,大家都把代码push到中央源.我认为它们的远程模式有如下几种: 1.U盘
 最常见的情况就是我在家和公司都要使用同一份源代码,于是我就会把中央源定在U盘上,而家里和公司的电脑各有一份本地副本,代码提交到本地,然后push到U盘上.例如我会在U盘上建立一个sparkle_repo的目录,放少量代码和一些文档用git管理.也有不少人是这样用SVN的,不过经常会遇到盘符变化的问题.
 优点是完全不需要网络,缺点也很明显,如果要跟朋友协作的话将会相当麻烦 2.网上邻居共享文件夹
 很简单,在本地网络随便找一台机器共享一个完全读写的文件夹,然后把中央源放在上面,适合公司内部的简单使用.
 优点是简单,缺点是,别人都能完全读写文件夹,干什么事情都可以了,包括删除整个目录.你当然可以进行权限认证,但是认证通过之后,一样可以做任何事情 3.ssh
 功能丰富的ssh对于传送文件当然不在话下(我工作的时候都是用ssh而不是ftp传送文件),最适合有个人ssh主机的情况,例如拥有一个dreamhost的空间,你只要在ssh帐户下随便开一个目录就能作为中央源,但是如果你要跟朋友协作的话,你还是得告诉他你的ssh帐号,又或者你对机器有足够的控制权可以让两个ssh帐号访问到同一个目录.另外,ssh比网络邻居要好的地方是你可以控制能够通过ssh的指令,这样可以只允许mercurial/git的指令通过,防止有意或无意的删除目录 
以上三种模式其实原理是一样的,就是通过一个大家都可以读写的目录进行协作 4.私有协议 
mercurial&git都可以启动一个daemon server进行使用,mercurial启动的port是8000,其实是使用http协议的,而经常见到的git://xxxxx就是git的私有协议.由于要启动额外的daemon,你必须对机器有一定的控制权才行,例如你不能在dreamhost这样使用. 5.http模式
 git只能通过http进行查看和pull,不能进行push操作,有点像viewcvs那样.这点来说,mercurial就比较厉害了,官方包里面提供了一个hgweb.cgi文件,通过配置这个cgi文件,我们可以在一个apache环境中提供push功能,也就是说我们可以在dreamhost上这样使用mercurial,非常棒(下一篇文章我将介绍怎么在dreamhost使用mercurial) 6.Don’t push to me, I will pull from you
 是不是有点像IOC(Don’t call me, I will call you).我阅读到相关资料的时候,看见这样一种模式,简直有如脑袋哐当一声.我们太以中央式版本管理的思路来想分布式版本管理了,认为一定要有一个中央源,然后大家都push数据到中央,而且还要认证什么的.git提出的这种模式,就是没有中央源,但是有中央人,并不是大家push到中央,而是中央从大家那里pull,其他人只要用某种形式,例如共享文件夹,或者http等方法公开你的副本,然后发email什么的通知中央人到你的副本中pull. 例如我sparkle负责整个项目,然后我只从各个模块的主管的源那里pull数据,而各个模块的主管从他的手下coder pull数据(事实上使用git的大型项目都是分成多个级别的),我熟悉模块主管,所以我知道他们是可信的,至于他们的数据从哪里来的我不关心,而他们也对他们的手下coder信任,从他们那里pull数据,如此一级一级下去.这种处理模式,一来不需要认证的部分,二来中央的数据是可控的,就是我负责,而不是多个人push的模式那样,并不一定能确定是否正确,第三点,可以分级.

我多次跟朋友讨论分布式版本管理软件的时候,都提到一个固有的缺陷,就是权限认证问题.传统的中央式版本管理软件,例如SVN,可以很简单地在服务器上做登录验证,可以阻止非法用户获取文件,当然,你可以使用一些外部手段来进行读取限制,例如http basic认证,iptables等手段,但是这样只能针对整个Mercurial库进行控制,不能像SVN那样对某一个目录树进行限制,你可以把不同的模块使用独立的Mercurial库来保存,但是那会增加管理的复杂性,而且你很难实现权限组的概念.不过,分布式版本管理最常用的地方是开源领域,也因此SVN比较适合公司内部使用,一般情况你也不希望员工能方便地把源代码带回家. 上面提到的是权限问题,另外一个比较大的就是认证问题.回想一下我们使用SVN的流程,我用sparkle&password登录SVN,然后提交修改,别人就能在SVN上看到这次的修改是我提交的,因为只有我才拥有sparkle这个帐号的密码,别人就没有办法冒认我.而使用Mercurial的时候,我们根本不用登录(当然有些远程模式可以配置需要登录,但是并没有认证效果,我在迟点专门写一篇远程模式的文章),使用Mercurial的时候,我们一般会先设置我们的名字,例如Sparkle,但是,别人一样可以取这个名字,你根本没有办法证明/阻止别人冒认你.又比如说我一个朋友Nomad的提交让我一起commit到center,我先把Nomad的修改pull到我这里,然后我再push到一个大家认为的公共库center,也就是说我同时把写着是我的修改和Nomad的修改提交,我随时可以假冒Nomad. 当然,你也可以认为大家都是守法的,比如说团队成员是可控的,但是这始终是个问题.因为没有了中心,也就没有了认证的可能性.其实有一个办法可以解决,就是使用证书签名,在我的提交里面,我附带一份使用我的私钥对此修改的签名,大家就可以通过公钥去验证这的确是我签发的,就能证明我的身份.不过目前大家还是比较少用这种模式,因为使用成本也挺高的.