Mercurial与TortoiseHg:新手指南与对比分析

5星 · 超过95%的资源 需积分: 50 39 下载量 105 浏览量 更新于2024-09-16 收藏 968KB DOC 举报
本文是一篇关于Mercurial(Hg)和TortoiseHg使用入门的教程,主要讲解了为何选择Mercurial作为分布式版本控制系统的原因。首先,分布式版本管理工具如Git和Hg因其高效性和灵活性而受欢迎,Linux采用Git进行源码管理,而Python和Firefox等项目则倾向于使用Hg。选择Mercurial的原因包括: 1. 适应性:对于汉化工作,分支需求相对较少,Git的优势在分支管理上,但对汉化团队而言,Git在Windows上的支持不如Hg方便,且ssh协议相比http更为复杂,不易教学。 2. 技术背景:Hg主要由Python实现,这可能对熟悉此语言的团队更有优势。然而,Hg的一个显著缺点是不支持针对单个文件夹的分支,翻译工作需要频繁处理文本而非图片,这使得全仓库复制成为必要。 3. 竞争分析:Google Code支持Hg而非Git,因为分析指出Hg在Windows友好、学习曲线平缓以及易于与Google架构(基于HTTP)集成等方面具有优势。虽然Git在技术上可能更强,但其在移植到特定环境(如Bigtable)时可能会遇到困难,且在HTTP场景下速度较Hg慢(约慢22倍和12倍)。 4. 免费代码托管:教程提到了GitHub,一个非常流行的代码托管平台,是免费的,这对于开发者来说是一个重要的选择因素。 这篇教程旨在帮助读者理解Mercurial和TortoiseHg的基本概念,并根据实际需求权衡Git和Hg的优缺点,以便做出适合自己的版本控制系统选择。通过本文,新手可以快速入门并掌握这两种工具的基础使用方法。
2011-06-09 上传
Mercurial 分布式版本管理工具 版本控制的发展趋势 在过去的四十年中,随着人们越来越熟悉他们的工具的能力和限制,开发和使用版本控 制工具出现了明确的趋势。 第一代软件开始于在个人计算机,人们用这些软件管理单个文件。虽然这些工具比手工 管理版本有了巨大的飞跃。但是加锁模型和依赖于单个计算机限制了他们使用范围,只用于 小的,组织严密的团队。 第二代软件放松了这些限制,因为它们采用了以网络为中心的结构,并且能够一次管理 整个项目。随着项目增长,又出现了新的问题。客户需要频繁的和服务器交互,服务器的可 伸缩性成为大项目的主要问题。不可靠的网络会妨碍客户和服务器的交互。随着开源项目开 始开放只读权限给匿名用户,没有提交权限的用户发现他们不能以自然的方式使用工具和项 目交互,因为他们不能记录他们的修改。 新一代的版本控制工具本质上是点对点的。所有的这些系统都抛弃了对单个中央服务器 的依赖,允许用户将他们的版本控制数据发布到任何需要的地方。通过互联网的协作摆脱了 技术的限制,走向选择和审查。现代的工具可以进行自治的,不受限制的离线操作。只需要 在有网络的时候和其他的版本库同步即可。 分布版本控制的优点 与它们的上一代竞争者相比,虽然分布式版本控制工具多年来已经很稳定和实用了,但 是旧的工具的使用者还没有完全了解它们的优点,分布式的工具在很多方面明显由于集中式 的工具。 对于个人开发者,分布式工具几乎永远比集中式工具快的多。原因很简单:集中式工具 的很多操作需要网络交互,因为大部分元数据都只在中央服务器上有一份拷贝。而一个分布 式工具将所有的元数据保存在本地。其他的相同,通过网络的交互增加了集中式工具的负 担。不要低估了反应迅速的工具的价值:你要花很多时间和你的版本控制软件交互。 分布式工具对你的服务器结构并不感冒,因为他们在将元数据复制到很多地方。如果你 的集中式系统和你的服务器着火了,你最好希望你的备份介质是可靠的,同时你最后的备份 是最近的,而且还能用。而对于分布式工具,你在贡献者的计算机上有很多备份。 网络的可靠性对分布式工具的影响要远远小于集中式工具。如果没有网络你根本不能使 用集中式工具,除了少数几个功能有限命令。而对于分布式工具,即使在你工作的时候网络 瘫痪了,你可能根本不会注意到。你不能做的事情仅仅是不能和其它计算机上的版本库交互 了,这种情况在本地操作相当罕见。而如果你的团队有异地的人员,那这就很有可能了。