Mercurial mercurial&git 的远程模式

liuxue.gu@hotmail.com · 2008年11月12日 · 6 次阅读

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 的模式那样,并不一定能确定是否正确,第三点,可以分级.

http://weavesky.com/2008/06/23/mercurial-git-remote/

暂无回复。
需要 登录 后方可回复。