Git，Mercurial和Bazaar的相对优势和劣势是什么？ [英] What are the relative strengths and weaknesses of Git, Mercurial, and Bazaar?
问题描述
这里的人们认为Git，Mercurial和Bazaar的相对优势和劣势是什么？
在考虑彼此之间以及版本控制系统像SVN和Perforce，应该考虑哪些问题？
在规划从SVN到其中一个分布式版本控制系统的迁移时，您会考虑哪些因素？
Git非常快速，扩展性非常好，并且对其概念非常透明。这是因为它有一个相对陡峭的学习曲线。一个Win32端口可用，但不是一流的公民。 Git将哈希值作为版本号显示给用户;这提供了保证（因为单个散列总是指完全相同的内容;攻击者不能在没有被检测到的情况下修改历史记录），但是对于用户而言可能是麻烦的。 Git具有跟踪文件内容的独特概念，即使这些内容在文件之间移动，并将文件视为第一级对象，但不会跟踪目录。 git的另一个问题是有很多操作（如 rebase ），这些操作可以很容易地修改历史记录（从某种意义上讲，由散列引用的内容永远不会改变，但引用该散列可能会丢失）;一些纯粹主义者（包括我自己）并不那么喜欢。
Bazaar速度相当快（对于历史较浅的树木而言速度非常快，但目前与历史长度相差甚远） ，并且很容易学习那些熟悉传统SCM（CVS，SVN等）的命令行界面的人。 Win32被开发团队视为一流的目标。它具有适用于不同组件的可插拔架构，并经常替换其存储格式;这使他们能够引入新的功能（例如更好地支持与基于不同概念的修订控制系统集成）并提高性能。 Bazaar团队考虑目录跟踪并重新命名支持一流的功能。虽然全球唯一的版本ID标识符可用于所有版本，但是使用树本地版本号（标准版本号，更类似于svn或其他更传统的SCM使用的版本号）来代替内容散列来标识修订版本。 Bazaar支持轻量级结账，其中历史保存在远程服务器上，而不是复制到本地系统，并在需要时通过网络自动引用;目前，这在DSCM中是独一无二的。
两者都有某种形式的SVN集成可用;然而，bzr-svn比git-svn更有能力，很大程度上是由于为此目的而引入的后端格式修订。 [更新，截至2014年：第三方商业产品SubGit提供SVN和Git之间的双向接口，与bzr-svn保真度相当，并且更加精美;我强烈建议在预算和许可限制允许的情况下将其用于git-svn。]
我没有使用Mercurial广泛的，所以不能详细评论它 - 除了要注意它像Git一样，对修订有内容哈希编址;也像Git一样，它不会将目录当作第一类对象（并且不能存储空目录）。但是，除了Git之外，它比任何其他DSCM都要快，并且比其他任何竞争对手都有更好的IDE集成（尤其是Eclipse）。考虑到它的性能特点（它仅略低于Git的性能）以及其出众的跨平台和IDE支持，Mercurial可能会吸引大量以win32为中心或IDE绑定成员的团队。
从SVN迁移出来的一个问题是，SVN的GUI前端和IDE集成比任何分布式SCM都要成熟。另外，如果您目前大量使用SVN预提交脚本自动化（即需要在提交之前进行单元测试才能继续），您可能需要使用类似于 PQM 用于自动将合并请求发送到共享分支。
SVK是一个使用Subversion作为其后盾的DSCM存储，并与SVN中心工具有很好的集成。然而，它的性能和可扩展性要比任何其他主要的DSCM（甚至Darcs）都要差很多，应该避免项目的历史长度或文件数量增加。
$ b
[关于作者：我使用Git和Perforce工作，Bazaar使用我的个人项目和嵌入式库;我的雇主组织的其他部门大量使用Mercurial。在以前的生活中，我围绕SVN建立了大量自动化;在此之前我有GNU Arch，BitKeeper，CVS等等的经验。起初Git非常令人厌恶 - 它感觉像GNU Arch，因为它是一个概念繁重的环境，与建立符合用户选择的工作流程的工具包不同 - 但我后来相当满意它]。
What do folks here see as the relative strengths and weaknesses of Git, Mercurial, and Bazaar?
In considering each of them with one another and against version control systems like SVN and Perforce, what issues should be considered?
In planning a migration from SVN to one of these distributed version control systems, what factors would you consider?
Git is very fast, scales very well, and is very transparent about its concepts. The down side of this is that it has a relatively steep learning curve. A Win32 port is available, but not quite a first-class citizen. Git exposes hashes as version numbers to users; this provides guarantees (in that a single hash always refers to the exact same content; an attacker cannot modify history without being detected), but can be cumbersome to the user. Git has a unique concept of tracking file contents, even as those contents move between files, and views files as first-level objects, but does not track directories. Another issue with git is that has many operations (such as rebase) which make it easy to modify history (in a sense -- the content referred to by a hash will never change, but references to that hash may be lost); some purists (myself included) don't like that very much.
Bazaar is reasonably fast (very fast for trees with shallow history, but presently scales poorly with history length), and is easy-to-learn to those familiar with the command-line interfaces of traditional SCMs (CVS, SVN, etc). Win32 is considered a first-class target by its development team. It has a pluggable architecture for different components, and replaces its storage format frequently; this allows them to introduce new features (such as better support for integration with revision control systems based on different concepts) and improve performance. The Bazaar team considers directory tracking and rename support first-class functionality. While globally unique revision-id identifiers are available for all revisions, tree-local revnos (standard revision numbers, more akin to those used by svn or other more conventional SCMs) are used in place of content hashes for identifying revisions. Bazaar has support for "lightweight checkouts", in which history is kept on a remote server instead of copied down to the local system and is automatically referred to over the network when needed; at present, this is unique among DSCMs.
Both have some form of SVN integration available; however, bzr-svn is considerably more capable than git-svn, largely due to backend format revisions introduced for that purpose. [Update, as of 2014: The third-party commercial product SubGit provides a bidirectional interface between SVN and Git which is comparable in fidelity to bzr-svn, and considerably more polished; I strongly recommend its use over that of git-svn when budget and licensing constraints permit].
I have not used Mercurial extensively, and so cannot comment on it in detail -- except to note that it, like Git, has content-hash addressing for revisions; also like Git, it does not treat directories as first-class objects (and cannot store an empty directory). It is, however, faster than any other DSCM except for Git, and has far better IDE integration (especially for Eclipse) than any of its competitors. Given its performance characteristics (which lag only slightly behind those of Git) and its superior cross-platform and IDE support, Mercurial may be compelling for teams with significant number of win32-centric or IDE-bound members.
One concern in migrating from SVN is that SVN's GUI frontends and IDE integration are more mature than those of any of the distributed SCMs. Also, if you currently make heavy use of precommit script automation with SVN (ie. requiring unit tests to pass before a commit can proceed), you'll probably want to use a tool similar to PQM for automating merge requests to your shared branches.
SVK is a DSCM which uses Subversion as its backing store, and has quite good integration with SVN-centric tools. However, it has dramatically worse performance and scalability characteristics than any other major DSCM (even Darcs), and should be avoided for projects which are liable to grow large in terms of either length of history or number of files.
[About the author: I use Git and Perforce for work, and Bazaar for my personal projects and as an embedded library; other parts of my employer's organization use Mercurial heavily. In a previous life I built a great deal of automation around SVN; before that I have experience with GNU Arch, BitKeeper, CVS and others. Git was quite off-putting at first -- it felt like GNU Arch inasmuch as being a concept-heavy environment, as opposed to toolkits built to conform to the user's choice of workflows -- but I've since come to be quite comfortable with it].
这篇关于Git，Mercurial和Bazaar的相对优势和劣势是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
