如何使 DVCS 与 Subversion 完全互操作？
DVCS 需要进行哪些架构更改才能与 Subversion 完全互操作？
许多 DVCS 都有某种与 Subversion 的双向接口，但也有限制和注意事项。例如，git-svn 可以创建一个镜像 Subversion 的存储库，并且对该存储库的更改可以通过“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 视为具有版本的事物之间没有直接映射，这是否意味着总会有一些活动无法在其中一个或另一个上正确记录？
What architectural changes would a DVCS need to be completely interoperable with Subversion?
Many DVCSs have some kind of bidirectional interface with Subversion, but there are limitations and caveats. For instance, git-svn can create a repository that mirrors Subversion, and changes to that repo can be sent back to Subversion via 'dcommit'. But the git-svn manpage explicitly cautions against making clones of that repository, so essentially, it's a Subversion working copy that you can use git commands on. Bazaar has a bidirectional Subversion capability too, but its documentation notes that Subversion properties aren't supported at all.
Here's the end that I'm pursuing. I want a Subversion repository and a DVCS repository that, in the steady state, have identical content. When something is changed on one, it's automatically mirrored to the other. Subversion users interact with the Subversion repository normally. DVCS users clone the DVCS repository, pull changes from it, and push changes back to it. Most importantly, they don't need to know that this special DVCS repository is associated with a Subversion repository.
It would probably be nifty if any clone of the special repository is itself a special repository and could commit directly to Subversion, but it might be sufficient if only the special repository directly interacts with Subversion.
I think that's what mostly needed is to improve the bidirectional capability so that changes to Subversion properties are translated to changes in the DVCS repository. Some changes in the DVCS repository would be translated to changes to Subversion properties.
Or is the answer to create a new capability in Subversion that interacts with a DVCS repository, using the DVCS repository as just a special storage layer such as fsfs or bdb?
If there's not a direct mapping between the things that Subversion and a DVCS regard as having versions, does that imply that there's always going to be some activity that cannot be recorded properly on one or the other?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在考虑了我得到的答案以及与其他人的一些对话之后，我的结论是，Subversion 和 DVCS 可以管理的事物之间必然需要存在一对一的映射。如果没有，真正的互操作性就不可能存在。
我认为现有的 DVCS 甚至都不适合此用途。正如 Chris Kaminski 指出的那样，也许 Subversion 将来会通过包含分布式功能来解决这个问题。
我问这个问题是因为我所在的组织即将结束从 CVS 到 Subversion 的漫长而痛苦的迁移。 Subversion 很好地满足了组织的需求——也就是说，拥有一个集中的事实来源。个体程序员希望使用 git 或其他流行的 DVCS 系统，这种情绪虽小但日益高涨。因为 git-svn 基本上只是一个奇特的 Subversion 客户端，所以有一个有点令人高兴的媒介。 OTOH，拥有集中存储库可能会引起烦恼，例如在印度工作的人的服务器延迟有数百毫秒。此外，我们所有的新员工迟早都会出现除了 git/hg/bzr/whatever 以外从未使用过任何东西的情况。我认为他们会对生活在集中式 Subversion 存储库的世界中感到恼火。
所以，我一直想知道是否有一种方法可以两全其美：组织想要的 Subversion 存储库以及围绕它构建的许多其他流程以及时髦程序员需要的闪亮的新 DVCS 工具！
可悲的是，我现在认为这实际上是不可能的。我认为我们正在与潮流作斗争 - 我相信 Subversion 的基本概念已经过时了。有一天，我们将不得不硬着头皮将 DVCS 技术融入到我们的基础设施中，然后让各个项目决定他们是想要生活在 Subversion 世界还是 DVCS 世界中。
My conclusion after thinking about the answers I got plus some conversations with others is that there would necessarily need to be a one-to-one mapping between the things that Subversion and the DVCS can manage. If there's not, the true interoperability cannot exist.
I don't think there are any existing DVCSes that are even candidates for this. As Chris Kaminski points out, perhaps Subversion will be tackling the problem in the future by including distributed capabilities.
I asked the question because I work in an organization where we're nearing the end of a long, painful migration from CVS to Subversion. Subversion meets the organization's needs very well - to wit, having a centralized source of truth. There's a tiny but growing groundswell of sentiment among individual programmers that they want to use git or other trendy DVCS systems. Because git-svn is basically just a fancy Subversion client, there's a somewhat-happy medium. OTOH, having the centralized repository can cause annoyance, e.g. someone working in India with hundreds of milliseconds of latency to the server. Furthermore, it's only a matter of time before all of our new hires show up not having ever used anything other than git/hg/bzr/whatever. I think they're going to chafe at living in the world of the centralized Subversion repository.
So, I have been wondering whether there was a way to have it both ways: the Subversion repository that the organization wants and around which many other processes are built AND the shiny new DVCS tools that hipster programmers demand!
Sadly, I now think that's just not really possible. I think we're fighting the tide - I believe that the underlying concepts of Subversion are obsolete. Someday, we're just going to have to bite the bullet and fit DVCS technology into our infrastructure, then let individual projects decide whether they want to live in a Subversion world or a DVCS world.
它称为 git，使用 git-svn 您可以与 Subversion 客户端进行互操作。 git-svn 的警告不是 git <-> svn，它是 (git <-> git) <-> svn。基本上他们是说，如果您使用 git 访问 SVN 存储库，请勿通过推/拉与其他人共享您的 git 存储库。否则它工作得很好。您通常会获得网络颠覆存储库的断开源代码控制。就这样。
如果您想要更“纯粹”的东西，可以使用 SVK，它是构建在 Subversion 之上的 DVCS，但它已被作者停止使用（尽管它是开源的 - PERL）。
subversion 人员在路线图上拥有一些 DVCS 功能，这可能是受到 SVK 的成功和 git/mercurial/bazaar 日益流行的推动。
It's called git, and using git-svn you can interoperate with Subversion clients. The caveat on git-svn isn't git <-> svn, it's (git <-> git) <-> svn. Basically they're saying that if you're using git to access an SVN repository, DON'T share your git repository with anyone else via push/pull. Otherwise it works just fine. You mostly get disconnected source code control of a networked subversion repository. That's all.
If you want something a little more "pure", there's SVK which is a DVCS built on top of Subversion, but it's been discontinued by the authors (though it is open source - PERL).
The subversion folks have some DVCS capabilities on the roadmap, probably spurred by the success of SVK and the growing prevalence of git/mercurial/bazaar.
我不认为有真正的本地方法可以使这两个工具完全互操作，特别是当您考虑到：
（请参阅SVN 与 Git）
所以希望“DVCS 端用户不需要知道 Subversion 存储库甚至存在。”有点牵强，至少没有像 克里斯在他的回答中建议。
我只是添加评估 svn2git 和 git2svn 以便让您的“DVCS 端用户”处理 git 存储库反映实际上应该是分支的“目录”。
（请参阅“使用 Git-Svn 克隆非标准 Svn 存储库”）
I don't think there is truly a native way to make both tools fully inter operable, especially when you consider that:
(see SVN vs. Git)
So wanting that "DVCS-side users don't need to know that a Subversion repository even exists." is a bit far fetched, at least without an intermediate git like Chris suggests in his answer.
I would simply add to evaluate svn2git and git2svn in order to have your "DVCS-side users" dealing with a git repo not reflecting "directories" which actually should have been branches.
(see "Cloning a Non-Standard Svn Repository with Git-Svn")