随着时间的推移，有些项目确实花了很多精力从ClearCase迁移到Subversion，但是我们仍然有一些人继续坚持使用ClearCase，因为它已经起作用了。
如今，Git似乎是许多人中的流行选择。 ，但我想知道我们是否可以将问题分为两个或三个子问题：
选择一个后端版本控制工具（例如Git）仅托管存储库。
如果需要，请选择一个或多个版本控制工具（例如Git，git-svn，git-hg，git-cc，GitSwarm），团队将使用这些工具与后端存储库进行交互，或者允许团队执行以下操作：选择自己的工具。
选择图形或基于Web的前端（例如TortoiseGit，Stash，SourceTree）进行交互是选择的版本控制工具，还是允许团队选择自己的工具。
这是在我们阅读了有关双重存储库的以下内容之后提出的，以允许不同的团队继续遵循其当前工作流程，直到他们已经准备好使用Git或我们最终决定迁移到的其他版本进行迁移： GitSwarm（Perforce和Git）
Mercurial和Git
后端版本控制工具应：
许可费用很少或没有。
支持Windows和Linux / UNIX存储库以及客户端。
理想情况下可以与旧的ClearCase和Subversion产品互操作，因此团队可以继续使用这些产品，直到他们决定迁移为止。
提供出色的性能，因此操作不会比现在使用ClearCase VOB和Subversion存储库慢得多。
将存储库数据保留为开放格式而不是专有容器，以便我们可以轻松地将存储库迁移到
如果需要，可以在另外5-15年内使用另一种工具。
如果可以这样做并且建议这样做，那么是否有适合我们的版本控制存储库可以开始研究和比较？
评论
我怀疑任何版本控制系统都使用标准格式。到目前为止，我已经看到Subversion，Git和Mercurial各自使用专有格式。无论如何，您都可以使用互操作性将整个项目历史记录复制到后面的另一个系统中。Git和Bazaar与SVN和几乎所有其他VCS系统都具有很好的双向通信。
@Alejandro您可能是指自定义格式。这些格式都不是专有格式。此外，诸如reposurgeon等工具已将git-fast-import格式确立为准标准。但是通常需要付出很多努力才能使其双向运行（Git及其Subversion桥除外）。