GIT / Mercurial 与 SVN 交叉用于开发团队
问题是我希望能够使用 Mercurial 或 git 作为开发前端，但在 Subversion 中进行了变更集和更新，通常是在集成分支或仅由脚本写入的分支中Mercurial，或者当 Hudson 注意到变化时由 Hudson 提供。然后我们的 Mercurial 存储库会使用其他使用 SVN 的开发人员所做的更改进行更新，我们将这些更改拉入并集成它们，并在提供新的开发版本之前测试更改等。
有谁知道以下情况对于合并的开发团队是否可能&分枝？或者是否有更好的方法......除了强大的武装人员只使用一种工具？
以下策略由以下组件组成：
- SVN SVN
- 与 Mercurial 的一对一克隆
- Mercurial 开发存储库
在下面的配置中，更新通常会从 SVN/trunk 拉入克隆 (hgsubversion)。克隆将是只读的，并且定期有一个脚本来提取更改。然后，克隆将被克隆到开发存储库中，该存储库是读写的（它是常规的 Mercurial 存储库）。当开发人员将更改推送到此开发人员存储库时，驻留在集成分支中的元素将被推送到 SVN/集成分支中。该分支仅由自动化脚本提交。如果其他使用 svn 的开发人员仅将更改推送到 SVN 的主干，则可以将它们拉入克隆并合并到 Mercurial 的环境中。缺点是您将失去更改来源的 SVN 级别的可见性。
[[[[ trunk [[[[[[[[[[[[[[[[[[[[[[[[ SVN ]]]]]]]]]]]] branch/integration ]]]]]]]]]]]]]]]]]]
| ^
| |
| |
v |
SVN - Mercurial Clone |
| |
| |
| |
v |
Mercurial - Development ---------------------------- Branch - Integration
The problem is that I'd like to be able to use Mercurial, or git, as a front end for development, but have changesets and updates made in Subversion, typically in an integration branch or something that is only written to by a script for Mercurial, or by Hudson when it notices changes. Then our Mercurial repository is updated with changes made by other developers who are using SVN, we pull the changes in and integrate them and test changes before providing new development version, etc.
Does anyone know if the following scenario is possible for development teams with merging & branching? Or if there's a better way...besides strong arming people to just use one tool?
The following strategy is composed of the following components:
- SVN
- 1-to-1 clone of SVN with Mercurial
- Mercurial Development Repository
In the configuration below, updates would typically be pulled from SVN/trunk into a clone (hgsubversion). The clone would be read-only, and periodically have a script that pulls for changes. The clone would then be cloned into a Development repository, which is read-write (it's a regular Mercurial Repo). When developers push changes to this developer repository, elements which reside in the Integration branch are pushed into SVN/integration branch. This branch is only committed to by an automated script. If other developers using svn only push changes into SVN's trunk, they can be pulled into the clone and merged inside Mercurial's environment. The downside would be that you would lose the visibility at an SVN level where changes came from.
[[[[ trunk [[[[[[[[[[[[[[[[[[[[[[[[ SVN ]]]]]]]]]]]] branch/integration ]]]]]]]]]]]]]]]]]]
| ^
| |
| |
v |
SVN - Mercurial Clone |
| |
| |
| |
v |
Mercurial - Development ---------------------------- Branch - Integration
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在使用 DVCS 的课程中，这实际上是我解释的主要用例之一，我认为它展示了 DVCS 的强大之处……
您有多种方法可以做到这一点。
手动方式
您SVN/checkout代码，然后Hg/init和Hg/commit一切。然后，您可以在 Hg 下进行工作，在本地根据需要进行小而频繁的原子修改。当您想要提交回 SVN 时，您首先Hg/up 到您在 SVN/checkout 之后所做的 Hg 修订。您SVN/up，不会出现 SVN 冲突，因为您刚刚从普通 SVN 修订版进行更新。您Hg/commit、Hg/merge，然后SVN/commit。如果有人同时在 SVN 中提交，则重复操作：Hg/up 到最后一个干净的 SVN 修订版、SVN/up 和 Hg/commit+merge< /强>。
您跟踪最新 SVN clean 修订版的方式取决于您。您可以使用每次更改的标签，将 SVN 修订版本保留在分支或单独的存储库中。 TIMTOWTDI
额外好处：这也是为使用 Hg 的人们充当 SVN 提交者的一种方式，而无需他们处于版本控制之外。
自动方式
我从来没有用过这种方式，但是 tailor 能够以两种方式进行 SVN/Hg 转换，反复。
In courses on using DVCS, that's actually one of the main use cases I explain, and one that I think shows how deeply awesome DVCSes are...
You have several ways to do it.
Manual way
You SVN/checkout the code, then Hg/init and Hg/commit everything. You then do your work under Hg, commiting small and frequent atomic modifications as you please, locally. When you want to commit back to SVN, you first Hg/up to the Hg revision you made just after the SVN/checkout. You SVN/up, there will be no SVN conflicts because you just updated from a plain SVN revision. You Hg/commit, Hg/merge and then SVN/commit. If someone has commited in SVN meanwhile, you repeat the operation: Hg/up to the last clean SVN revision, SVN/up and Hg/commit+merge.
The way you keep track of the last SVN clean revision is up to you. You could use a tag that you change each time, keep the SVN revisions in a branch or in a separate repository. TIMTOWTDI
Added benefit: this is also a way to serve as an SVN committer for people using Hg, without them being outside version control.
Automatic way
I've never used it that way, but tailor is able to do SVN/Hg conversion both ways, repeatedly.