如何使DVCS与Subversion完全互操作？

Question

DVCS需要进行哪些架构更改才能与Subversion完全互操作？

许多DVCS都有一些带有Subversion的双向接口，但也有一些限制和注意事项。例如，git-svn可以创建一个镜像Subversion的存储库，并且可以通过'dcommit‘将对该存储库的更改发送回Subversion。但git-svn手册页明确警告不要克隆该存储库，因此从本质上讲，它是一个Subversion工作副本，您可以在其上使用git命令。Bazaar也具有双向Subversion功能，但其文档指出根本不支持Subversion属性。

这就是我追求的目标。我想要一个Subversion存储库和一个DVCS存储库，它们在稳定状态下具有相同的内容。当其中一个上的内容发生更改时，它会自动镜像到另一个上。Subversion用户通常与Subversion存储库交互。DVCS用户克隆DVCS存储库，从中提取更改，并将更改推送回该存储库。最重要的是，他们不需要知道这个特殊的DVCS存储库与Subversion存储库相关联。

如果特殊存储库的任何克隆本身是一个特殊存储库，并且可以直接提交给Subversion，这可能会很好，但如果只有特殊存储库直接与Subversion交互，这可能就足够了。

我认为最需要的是改进双向功能，以便将Subversion属性的更改转换为DVCS存储库中的更改。DVCS存储库中的一些更改将转换为对Subversion属性的更改。

或者，答案是在Subversion中创建与DVCS存储库交互的新功能，将DVCS存储库仅用作特殊存储层，如fsfs或bdb？

如果Subversion和DVCS认为具有版本的事物之间没有直接的映射，这是否意味着总会有一些活动无法在其中之一上正确记录？

Answer 1

在考虑了我得到的答案以及与其他人的一些对话后，我得出的结论是，Subversion和DVCS可以管理的东西之间必须存在一对一的映射。如果没有，那么真正的互操作性就不可能存在。

我不认为有任何现有的DVCSes是这方面的候选。正如Chris Kaminski所指出的，也许Subversion将来会通过包含分布式功能来解决这个问题。

我之所以问这个问题，是因为我所在的组织即将结束从CVS到Subversion的漫长而痛苦的迁移。Subversion很好地满足了组织的需要--也就是说，它有一个集中的真理来源。在个人程序员中，有一种很小但越来越多的情绪，他们想要使用git或其他时髦的DVCS系统。因为git-svn基本上只是一个花哨的Subversion客户机，所以有一个有点令人满意的中间版本。OTOH，拥有集中式存储库可能会造成麻烦，例如，在印度工作的人在服务器上有数百毫秒的延迟。此外，我们所有的新员工都没有使用过git/hg/bzr/其他任何东西，这只是个时间问题。我想他们会对生活在集中式Subversion存储库的世界感到恼火。

因此，我一直在想，是否有一种方法可以两全其美:组织想要的Subversion存储库，以及潮人程序员所需要的闪亮的新DVCS工具！

遗憾的是，我现在认为这是不可能的。我认为我们正在与潮流作斗争--我相信颠覆的基本概念已经过时了。总有一天，我们将不得不咬紧牙关，将DVCS技术融入到我们的基础设施中，然后让单个项目决定他们是想要生活在颠覆世界还是DVCS世界。

Answer 2

它被称为git，使用git-svn可以与Subversion客户端进行互操作。关于git-svn的警告不是git <-> svn，而是(git <-> git) <-> svn。基本上，他们的意思是，如果你使用git访问SVN存储库，不要通过推送/拉入与任何人共享你的git存储库。除此之外，它工作得很好。大多数情况下，网络subversion存储库的源代码控制是断开连接的。就这样。

如果你想要一些更“纯粹”的东西，有一个SVK，它是一个构建在Subversion之上的DVCS，但它已经被作者停止使用(尽管它是开源的- PERL)。

subversion人员在路线图上有一些DVCS功能，这可能是受SVK的成功和git/mercurial/bazaar日益流行的推动。

Answer 3

我不认为有真正的本机方法来使这两个工具完全互操作，特别是当你考虑到：

Git

• SVN是一个版本控制，它用directories

• SVN模拟标签和分支，不像做那样记录合并信息

(参见SVN vs. Git)

所以希望“DVCS端用户甚至不需要知道Subversion存储库的存在”。这有点牵强，至少没有像Chris suggests in his answer这样的中间git。

我将简单地添加评估和，以便让您的“DVCS端用户”处理git代码库，而不是反映实际上应该是分支的“目录”。

(参见"Cloning a Non-Standard Svn Repository with Git-Svn")