我可以在本地使用 Mercurial，并从 Subversion 存储库更新/推送到 Subversion 存储库吗？
作为一名自由职业者，我经常在使用 Subversion 存储库的公司工作。
如果我可以使用 Mercurial 从这些存储库获取代码，在离线时跟踪我的更改，然后在我重新上线时将所有本地更改提交到公司的 Subversion 服务器，那就太方便了。
这有效吗？您是否阅读过有关具体细节的优秀教程？
As a freelancer, I often work at companies who use Subversion repositories.
It’d be handy if I could use Mercurial to get code from these repositories, track my changes when I’m offline, and then commit all my local changes to the company’s Subversion server when I’m back online.
Does this work? Have you read any good tutorials on the specifics?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我在一家使用 CVS 的公司工作，因此 HgSubversion 不是一个选择。几天前我有同样的问题，并基于此开发了一个工作流程：
http://momentaryfascinations.com/programming/how.to.use.mercurial.for.local.source.code.management.with.a .public.subversion.server.html
我在我的 CVS 存储库所在的位置创建了一个 Mercurial 存储库，我将其视为“只读”。然后，我将这个“只读”hg 存储库克隆到工作存储库，在本地进行更改/修复。我一直在克隆我所做的每一项功能和修复的存储库，但您也可以只拥有一个存储库，并使用不同的分支策略来管理您的开发。以下是此类策略的详细概述 。
此工作流程的关键是拥有“只读”存储库。我曾经在我创建的第一个 Mercurial 存储库中进行更改，该存储库位于 CVS 之上。这有效，但从 CVS 更新时变得混乱。通过这个附加层，您可以单独处理自己的更改和 CVS 更新。
与 CVS 保持同步
每当 CVS 发生变化时，我都会进行 cvs 更新。对于“只读”hg 存储库，这将显示为修改后的文件。要同步 Mercurial，我只需执行以下操作
（因此，您将在我的 hg 日志中看到很多此类消息）。此时，我的“只读”存储库已与 CVS 同步。现在，我可以转到我克隆的任何存储库并发出
hg pull，然后发出hg update来同步它们。将更改从 hg 提交回 CVS
另一方面，当我想要提交到 CVS 时，我将进入我的一个工作存储库，在该存储库中我已经将更改提交到了 hg。然后我将我的更改推送回“只读”，跳转到“只读”存储库，执行
hg 更新。从 CVS 的角度来看，这将看起来像是刚刚修改过的。然后，我将cvs commit返回到 CVS。在这里，我必须在日志消息中重复/总结我在 hg 存储库中所做的工作。诚然，这个工作流程中存在一些困难。您可能在 hg 中进行了多项更改，这总共只对 CVS/SVN 进行了一项更改，因此历史记录将不会保留在 CVS/SVN 中，并且您必须总结您的提交消息。您必须手动管理保持 CVS 和“只读”存储库同步。这样做的优点是您不需要安装任何额外的扩展 - 您只需从两个角度处理文件本身。发生的一切都非常透明并且在您的控制之下。
我仍在尝试 hg，但到目前为止，这个工作流程运行得相当不错。
Harvey 提供了一个很好的图表，并指出此工作流程适用于任何其他 VCS：
（来源：sr105.com）
I'm working at a company that is using CVS, so HgSubversion wasn't an option. I had the same question a few days ago and developed a workflow based on this:
http://momentaryfascinations.com/programming/how.to.use.mercurial.for.local.source.code.management.with.a.public.subversion.server.html
I created a Mercurial repository where my CVS repository is, which I treat as "readonly". I then clone this "readonly" hg repo to working repositories, where I make changes/fixes locally. I have been cloning the repo for every feature and fix that I make, but you could also just have one repo, and use a different branching strategy to manage your development. Here's a good overview of such strategies.
The key to this workflow is having that "readonly" repository. I used to make my changes in the first Mercurial repository I created, which was on top of CVS. This worked, but it got confusing when updating from CVS. By having this additional layer, you can deal with making your own changes and updating from CVS separately.
Keeping in sync with CVS
Whenever there are changes in CVS, I do a cvs update. To the "readonly" hg repository, this will show up as modified files. To sync up Mercurial, I simply do a
(So, you'll see a lot of those messages in my hg logs). At this point, my "readonly" repository is sync'ed with CVS. Now I can go to any of the repositories I've cloned and issue a
hg pulland thenhg updateto sync them up.Committing changes from hg back to CVS
Going the other direction, when I want to commit to CVS, I'll go into one of my working repositories where I've committed my changes already to hg. Then I
hg pushmy changes back to "readonly", hop over to the "readonly" repository, do anhg update. From CVS's perspective, this will appear as freshly modified. I then do acvs commitback into CVS. Here I'll have to repeat/summarize in my log message the work that I've done in my hg repository.Admittedly, there are rough spots in this workflow. You could be making multiple changes in hg, which add up to just one change in CVS/SVN, so that history will not be kept in CVS/SVN, and you'll have to summarize your commit messages. You have to manually manage keeping CVS and your "readonly" repository in sync. The advantage of this is that you don't need to install any additional extensions - you are just dealing with the files themselves from both perspectives. Everything that is happening is pretty transparent and under your control.
I'm still cutting my teeth on hg, but so far this workflow has been working out reasonably well.
Harvey has provided a nice diagram of this and makes an excellent point that this workflow applies to any other VCS:
(source: sr105.com)
尝试 HgSubversion。它可以让你做到这一点。您可以将（部分）svn 存储库本地克隆到 hg 存储库，并在本地使用 hg 并远程使用 svn（推送和拉取执行您期望的操作）。
我过去曾使用过它并取得了一些成功，但没有丰富的经验。
Try HgSubversion. It allows you to do just that. You can clone a (part of) svn repository locally to an hg repository and work with hg locally and svn remotely (push and pull do what you would expect of them).
I have used it with some success in the past but do not have extensive experience with it.
您可以在此wiki 页面上找到一些信息。
You can find some info on this wiki page.