DVCS需要与Subversion完全互操作的架构变化是什么？
许多DVCS与Subversion有某种双向接口，但存在局限性和警告。例如，git-svn可以创建一个镜像Subversion的存储库，对该repo的更改可以通过'dcommit'发送回Subversion。但是git-svn联机帮助页面明确警告不要制作该存储库的克隆，所以基本上，它是一个可以使用git命令的Subversion工作副本。 Bazaar也具有双向Subversion功能，但其文档指出Subversion属性根本不受支持。
这是我追求的目标。我想要一个Subversion存储库和一个DVCS存储库，它在稳定状态下具有相同的内容。当一个东西被改变时，它会自动镜像到另一个。 Subversion用户通常与Subversion存储库交互。 DVCS用户克隆DVCS存储库，从中提取更改并将更改推送回它。最重要的是，他们不需要知道这个特殊的DVCS存储库与Subversion存储库相关联。
如果特殊存储库的任何克隆本身是一个特殊的存储库并且可以直接提交给Subversion，那么它可能会很有用，但如果只有特殊的存储库直接与Subversion交互，它可能就足够了。
我认为最需要的是改进双向功能，以便将Subversion属性的更改转换为DVCS存储库中的更改。 DVCS存储库中的某些更改将转换为Subversion属性的更改。
或者是在Subversion中创建一个与DVCS存储库交互的新功能的答案，使用DVCS存储库只是一个特殊的存储层，如fsfs或bdb？
如果Subversion和DVCS认为有版本的东西之间没有直接映射，那是否意味着总会有一些活动无法在其中一个上正确记录？
答案 0 :(得分：3)
在考虑了我得到的答案以及与他人的一些对话之后，我的结论是，Subversion和DVCS可以管理的事情之间必然需要一对一的映射。如果没有，真正的互操作性就不存在了。
我认为现有的DVCS甚至不是候选人。正如Chris Kaminski所指出的那样，也许Subversion将通过包含分布式功能来解决这个问题。
我问了这个问题，因为我在一个组织工作，我们即将结束从CVS到Subversion的漫长而痛苦的迁移。 Subversion很好地满足了组织的需求 - 具有集中的真实来源。在个别程序员中，他们想要使用git或其他时髦的DVCS系统，这是一个微小但不断增长的情绪。因为git-svn基本上只是一个花哨的Subversion客户端，所以有一种有点幸福的媒介。具有集中存储库的OTOH可能引起烦扰，例如有人在印度工作，服务器有数百毫秒的延迟。此外，我们所有新员工出现之前没有使用过除git / hg / bzr /之外的任何东西，这只是时间问题。我认为他们会生活在集中式Subversion存储库的世界中。
所以，我一直想知道是否有两种方法可以实现这两种方式：组织需要的Subversion存储库以及构建许多其他流程的工具以及时髦程序员所需的闪亮的新DVCS工具！
可悲的是，我现在认为这是不可能的。我认为我们正在逆势而上 - 我相信Subversion的基本概念已经过时了。有一天，我们将不得不咬紧牙关，将DVCS技术融入我们的基础设施，然后让个别项目决定他们是想要生活在Subversion世界还是DVCS世界。答案 1 :(得分：1)
它被称为git，使用git-svn可以与Subversion客户端进行互操作。关于git-svn的警告不是git＆lt; - ＆gt; svn，它是（git＆lt; - ＆gt; git）＆lt; - ＆gt; SVN。基本上他们说如果你使用git访问SVN存储库，不要通过push / pull与其他任何人共享你的git存储库。否则它工作得很好。您通常会获得联网的subversion存储库的不连续源代码控制。就这样。
如果你想要一些更“纯粹”的东西，那么SVK就是一个建立在Subversion之上的DVCS，但作者已经停止了它（尽管它是开源的 - PERL）。
颠覆人员在路线图上有一些DVCS功能，可能是由于SVK的成功和git / mercurial / bazaar的日益普及所激发的。
答案 2 :(得分：1)
我认为没有一种真正的本地方式可以让两种工具完全互操作，特别是考虑到这一点：
（见SVN vs. Git）
所以想要“DVCS端用户不需要知道甚至存在Subversion存储库。”有点牵强，至少没有像Chris suggests in his answer那样的中间git。
我只需添加评估 svn2git 和 git2svn ，以便让您的“DVCS端用户”处理git repo不反映实际应该是分支的“目录” （参见“Cloning a Non-Standard Svn Repository with Git-Svn”）