使用 Mercurial 处理只读 SVN 存储库：合并来自主干的更新
我可以访问 SVN 存储库，我可以偶尔获取修订版本的快照（例如 .gz，而不是通过 svn update），并且正在修改代码以添加一些我无意推送的自定义内容回到 SVN 存储库。我正在使用 Mercurial 来管理我的本地副本，并且已经看到了两种处理这种情况的方法。
基于 https://www.mercurial-scm.org/ 中列出的方法wiki/SubversionToMercurialHowto，您将未修改的 svn 存储库存储在一个分支中，在另一个分支中工作，然后更新 svn 并将更改拉过来并合并冲突。
只需保留两个独立的存储库，并从基于 svn 的克隆执行
hg pull -f到工作克隆，然后合并冲突。
我想知道一种方法相对于另一种方法是否有优势，以及如何处理我无法轻松更新 svn 副本，而可能必须重写整个存储库的事实（除非有另一种方法）有选择地替换已更改的文件）。
I have access to an SVN repository that I can grab occasional snapshots of revisions (as .gz, not through svn update) and am hacking the code to add some customizations that I do not have any intention of pushing back to the SVN repo. I'm using mercurial to manage my local copy and have seen two ways of dealing with this situations.
Based on the approach laid out at https://www.mercurial-scm.org/wiki/SubversionToMercurialHowto, you store the unmodified svn repo in one branch, work in the other and then update the svn and pull changes over and merge conflicts.
Just keep two independent repos and do a
hg pull -ffrom the svn based clone into the working one and then merge the conflicts.
I was wondering if there was an advantage to one approach over the other, and how to deal with the fact that I can't easily update the svn copy, and instead probably have to re-write the whole repo (unless there is another way to selectively replace files that have changed).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
根据这个其他问题的答案，我要说最好使用命名分支而不是克隆，因为跟踪更改的来源存在差异（如果这对您的情况很重要）。将来自 Subversion 存储库的更改与克隆或命名分支合并基本上是相同的，并且更改来自何处（SVN、您的提交等）也无关紧要。 Mercurial 将能够处理合并。
此外，Svn2Hg 操作方法解释了一种能够返回统一差异 到 SVN 存储库。因此，如果您无法承诺，您应该能够向某人提供统一的差异来应用您想要回馈的更改。
最后，如果您最终获得了 SVN 存储库的访问权限，您将需要使用 hgsubversion 扩展 会将 Hg 转变为 SVN 客户端，并允许您将更改直接推送回 SVN 存储库。
Based on the answer to this other SO question, I'm going to say it will be better to use named branches rather than cloning because of the differences in tracking where changes came from (if that matters in your situation). Merging changes incoming from the Subversion repository with either cloning or named branches is basically the same and where the changes are coming from (SVN, your commits, etc) is also irrelevant. Mercurial will be able to handle the merges.
Also, the Svn2Hg how-to explains a method of being able to give back a unified diff to the SVN repository. So, if you're not able to commit to it, you should be able to give someone a unified diff to apply those changes you want to give back.
Lastly, if you do eventually gain access to the SVN repo, you'll want to use the hgsubversion extension which will turn Hg into a SVN client and allow you to push changes directly back to the SVN repo.