可用于嵌入式软件开发的最快 SCM 工具
在我的公司，目前我们正在使用 Rational Clearcase 作为我们嵌入式软件开发的软件配置管理工具。该软件基本上是针对汽车的，特别是针对发动机的（我认为这些信息并不重要）。 但我发现 Clearcase 在执行任何活动（访问文件、分支和标签）时都非常慢，此外还有各种其他限制。
我们最近决定研究一些免费的&开源的分布式版本控制系统，能够快速高效地处理我们的大型项目。该工具应该是一个成熟的存储库，具有完整的历史记录和完整的修订跟踪功能，而不依赖于网络访问或中央服务器。分支和合并快速且容易完成。它应该具有多站点开发设施。
根据上述要求，我们提出了一些目前市场上可用的工具：
GIT、Mercurial、Bazaar、Subversion、CVS、Perforce 和 Visual SourceSafe。
我需要大家的帮助来为我找到一个合适的 SCM 工具来满足上述要求。
预先感谢您， 拉哈马斯。
In my company, presently we are using Rational clearcase as the Software Configuration Management tool for our Embedded software development. The software is basically for Automobiles, to be specific for Engines (I dont think these information really matters).
But I find Clearcase to be very slow is performing any the activities (accesing files, branching and labelling), in addition to which there are various other limitations.
We have recently decided to research on some free & open source, distributed version control system which could be able to handle our large projects with speed and efficiency. This tool should be a full-fledged repository with complete history and full revision tracking capabilities, not dependent on network access or a central server. Branching and merging are fast and easy to do. It should have multisite development facility.
With these above mentioned requirement, we have come up with some of the tools that are presently available in the market:
GIT, Mercurial, Bazaar, Subversion, CVS, Perforce, and Visual SourceSafe.
I need everybody's help in finding me an approrpiate SCM tool for me which meets the above mentioned requirements.
Thanking you in Advance,
Rahamath.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
Mercurial 或 Git 是最流行的分布式版本控制系统。我相信 Git 具有速度优势，特别是在提交、分支和合并方面。此外，它的合并算法是我见过的最好的；大多数合并可以自动处理，无需用户输入。
根据我自己的经验，如果不是因为它的学习曲线非常陡峭，我会毫不犹豫地推荐 Git。然而，我认为这很大程度上是由于切换到 DVCS 时的范式转变，例如掌握推和拉的窍门，这是存储库去中心化的方式。
Subversion、CVS、Perforce 和 SourceSafe 均未分发；此外，Perforce 和 SourceSafe 既不是免费的也不是开源的。 CVS 几乎已经过时了，Subversion 是它的自然继承者，所以我不会再进一步考虑它。
Mercurial or Git are the most popular Distributed Version Control Systems. I believe Git has the speed advantage, particularly in committing, branching and merging. Furthermore, its merging algorithm is the best I've yet come across; most merges can be handled automatically without user input.
From my own experience, I would recommend Git without hesitation were it not for its very steep learning curve. However, I believe much of this is due to the paradigm shift when switching to a DVCS, such as getting the hang of pushing and pulling, the way repositories become decentralised.
Subversion, CVS, Perforce and SourceSafe are not distributed; furthermore, Perforce and SourceSafe are neither free nor open source. CVS is all but obsolete, with Subversion being its natural successor, so I wouldn't consider it any further.
如果您想要“不依赖于网络访问或中央服务器”的东西，那么您列表中的集中式 SCM（Subversion、CVS、p4）就必须放弃。
如果你想要跨平台，那么我认为 Visual Source Safe 就必须去。
另外，您提到了开源，它淘汰了 p4 和 Visual Source Safe。
CVS 已经很老了，如果您打算使用它，最好忽略它并使用 SVN。
Git 是您可以添加到列表中的东西，但它在 Windows 上的支持不如 bzr 和 Mercurial。
我自己使用 git，但我专门在 Gnu/Linux 上进行开发，因此无法评论 Windows 支持。另外，它有点古怪，但一旦你习惯了，它就会非常强大。存在学习曲线问题，因此您可能需要花一些时间来培训您的团队使用该工具。
博兹尔，我不知道。当我最后一次接触它时，它存在存储库格式问题并且速度非常慢。现在好多了，但第一次接触让我伤痕累累。
Hg 很不错，在 Windows 和 Gnu/Linux 上运行良好，但由于我大量使用 git，所以我怀念它在 hg 上的一些功能。
If you want something "not dependent on network access or a central server", then the centralised SCMs from your list (Subversion, CVS, p4) have to go.
If you want cross platform, then I think Visual Source Safe would have to go.
Also, you mentioned Open Source, that kicks out p4 and Visual Source Safe.
CVS is quite old and if you're planning to use that, you'd best ignore it and use SVN instead.
Git is something that you can add to the list but it's support on windows is not as good as that of bzr and mercurial.
I use git myself but I develop exclusively on Gnu/Linux and so can't comment on windows support. Also, it's a bit quirky but once you get used to it can be really powerful. There is a learning curve problem so you might have to spend some time training your team on the tool.
Bzr, I don't know. When I last touched it, it had repository format issues and was horribly slow. It's much better now but I was scarred by my first exposure.
Hg is sweet and works fine on windows and Gnu/Linux but since I've used git quite heavily, I miss some of it's features on hg.
我们正在使用 ClearCase （及其优点和痛点），我们正在考虑DVCS。
现在，我们正在 Windows (msysgit) 和“中央”Solaris 服务器上引入 Git，它确实满足了我们在合并方面的需求，以及在分发方面（用于离岸开发） ）
但是我们必须设置“中央”存储库供开发人员用作参考，为此我们必须使用 gitolite（pu 分支）的细粒度访问级别（存储库、分支、每个用户或每个组的目录访问、基于 ldap）
与 Eclipse 正在进行中，我们对支持充满信心级别，因为所有 Eclipse 项目都已从 CVS 切换到 Git（因此他们致力于支持它）。
Mercurial 已被考虑并且当然可以提供相同级别的功能，但具有 非常复杂的分支模型。
Git 没有需要安装的扩展。它确实有效（通过我的用户支持服务，我们设法将学习曲线保持在合理的水平）
We are using ClearCase (with its advantages and pain points), and we are considering DVCS.
Right now, we are introducing Git, both on Windows (msysgit) and on a "central" Solaris server, which does met our needs in term of merging, and in term of distribution (for offshore-development)
But we have to setup "central" repositories for the developers to use as reference, and for that we had to use gitolite (the pu branch) for its fine-grained access level (repo, branch, directory access per user or per group, ldap-based)
The integration with Eclipse is in progress, and we are confident on the support level since all Eclipse projects have switched from CVS to Git (so they are committed to support it).
Mercurial has been considered and can certainly offer the same level of features, but has a much complex branching model.
Git has no extension to install. It just works (with a learning curve we manage to keep at a reasonable level through my user support services)
在工作中，我们实际上也在 ClearCase 上，并且由于某些原因不满意...更新大型项目非常慢（特别是如果不是本地网络）...
我们（不是我）对一些产品进行了基准测试，Mercurial 被选为未来使用的解决方案。
At work we are actually on ClearCase too and not satisfied for the some reasons... Very slow to update big projects (particularly if not local network)...
We (not me) benchmarked some products and Mercurial was choosen to be the future solution used.