在本地使用 Mercurial 并远程使用 SVN？
在工作中，我们使用 Subversion，但是因为没有人知道如何对我们的“分支”进行分支，涉及复制整个代码库并将其视为单独的存储库 - 这意味着我们对“补丁”分支所做的任何更改都需要复制/粘贴到主要开发（“主干”）分支，因此它们是同步的，我们不能使用任何内置合并工具（我们手动使用 WinMerge 或类似工具来查找更改的行）。没有人愿意花时间学习如何使用 SVN 的分支功能，而是鼓励使用此策略作为替代方案。
由于我无法说服其他人研究真正的分支，因此我正在考虑为自己做一些事情来减少合并的痛苦。如果我能获得支持的话，我想研究 Mercurial 一段时间了（我之前在我的 Mac 上使用过一点 Git；工作中使用的是 Windows7）作为批发 SVN 的替代品。
我的问题是：首先，如果我必须将更改推送到两个 SVN 存储库，那么在我的本地计算机上使用 Mercurial 是否会很困难？在本地，我可以使用分支轻松地将代码合并回来，保持 SVN 存储库不同将是一个简单的问题，只需将分支推送到补丁代码，并将 dev 分支（当然合并后）推送到 SVN 中的 dev 分支，对吧？
其次，在介绍 Mercurial 之前，有没有更好的方法来做到这一点？我试图告诉我的同事关于使用 SVN 的分支，但我得到的答案是“这暂时有效”，因为没有人愿意花时间学习 SVN 分支，并且 100% 诚实地说，我从未使用过 SVN我自己进行分支，所以我不确定它使用起来有多容易/困难，并且不想冒险尝试分支并弄乱一些东西。
At work we use Subversion, but because nobody understands how to branch our "branching" involves copying the entire codebase and treating it as a separate repository - this means any changes we do to the "patch" branch need to be copied/pasted to the main development ("trunk") branch so they are in sync and we cannot use any built-in merging tools (We manually using WinMerge or similar to find the lines that changed). Nobody wants to take the time out to learn how to use SVN's branching capabilities and instead encourage using this strategy as an alternative.
Since I cannot convince everyone else to look into real branching, I'm looking at doing something for myself to make the merges less painful. I have wanted to look into Mercurial for a while now (I have previously used Git a little on my Mac; Windows7 at work) as a wholesale SVN replacement if I could get buy-in.
My question is this: First, would it be difficult to use Mercurial on my local machine if I would have to push changes out to two SVN repositories? Locally I could use branching to merge the code back in easily, keeping the SVN repos different would be a simple matter of pushing the branch to the patch code, and the dev branch (after merging of course) to the dev branch in SVN, right?
Second, before I introduce Mercurial is there a better way of doing this? I've tried to tell my co-workers about using SVN's branching but the answer I get is that "this works for now" as nobody wants to take the time to learn SVN branching, and to be 100% honest I have never used SVN branching myself so I'm not sure how easy/hard it is to use, and don't want to risk trying to branch and messing something up.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
首先，说实话，如果你得到关于 SVN 分支最基本的东西的这种回应，你真的认为你可以说服他们切换整个存储库系统吗？
但可以肯定的是，“不想冒险尝试分支并弄乱某些东西”是 SVN 的典型特征，而 Mercurial 在这方面做得更好；由于您始终在本地存储库中工作，因此尝试和犯错误的成本很低，如果搞砸了，您可以创建一个新的克隆。在几乎任何情况下，除了必须保存大量二进制数据的存储库（例如艺术存储库）之外，我肯定会推荐 Mercurial 而不是 SVN。
现在对于您的问题，
原则上，您可以对 Mercurial 存储库和 SVN 存储库使用相同的工作目录。您可能想要将 .hg 和 .svn 添加到 SVN 和 Mercurial 的忽略过滤器，当然，您提交给 Mercurial 的更改不会自动提交给 SVN。不过，使用 Mercurial 作为本地开发的暂存器会很方便。如果您想要在两个 SVN 签出中执行此操作，您确实可以通过从一个到另一个的拉取或推送来在 Mercurial 克隆之间交换数据。
不过说实话，针对你的第二个问题，我认为“更好的方法”就是学习 SVN 的分支和合并机制。在 SVN 之上运行 Mercurial 可能非常麻烦，而且可能会带来更多麻烦。如果您想尝试 SVN 合并，您可以创建一个测试 SVN 存储库来练习分支和合并。
如果您的同事已经决定使用 SVN 并且不关心 Mercurial，那么您可能只能忍受它。也许有一些安慰，因为有很多类似的情况，我个人希望尽快停止使用 SVN，但不幸的是，在我以前和现在的公司中，我仍然坚持使用它。尽管在我现在的公司，他们愿意在未来的某个时候改变它，而且我们已经在使用 git 来开发一个外部项目。
我可能应该提到的另一件事是：有一些工具，例如 hgsubversion 扩展，允许您在 SVN 之上使用 Mercurial，将所有提交转换为 Mercurial 提交。不过，我真的不建议这样做，特别是如果您是 Mercurial 新手，SVN 和 Mercurial 之间的根本不匹配意味着，如果您想推迟更改，那么分支实际上是不可能的，您必须始终重新建立基础，并且您很容易就会丢失数据。
First of all, to be honest if you’re getting this kind of response about the most basic things of SVN branching, do you really think you could convince them to switch their entire repository system?
For sure though, “don’t want to risk trying to branch and messing something up” is very typical of SVN, and something that Mercurial does a lot better; as you are always working in a local repository, experimenting and making mistakes is cheap and you can just make a new clone if you mess up. I would definitely recommend Mercurial over SVN in pretty much any situation except for repositories that must hold large amounts of binary data such as art repositories.
Now as for your questions,
In principle, you can use the same working directory for a Mercurial repository and an SVN repository. You probably want to add .hg and .svn to SVN and Mercurial’s ignore filters, and of course changes you commit to Mercurial don’t automatically commit to SVN. However it can be convenient to use Mercurial as a scratchpad for local development. If you have two SVN checkouts you want to do this in, you can indeed just exchange data between Mercurial clones by pulling or pushing from the one to the other.
To be honest though, in response to your second question, I think the ‘better way’ is just to learn SVN’s branching and merge mechanics. Running Mercurial on top of SVN can be pretty cumbersome, and may be more trouble than it’s worth. If you want to experiment with SVN merging, you could make a test SVN repository to practice branching and merging there.
If your coworkers have decided on SVN and can’t be bothered about Mercurial, you probably just have to live with it. Maybe there is some consolation in the fact that there are many in similar situations, I’d personally love to stop using SVN sooner rather than later, but still in my previous and current company I’m unfortunately stuck with it. Although at my current company, they’re open to changing it at some point in the future and we’re already working with git for an external project.
One more thing I should probably mention: there are tools like the hgsubversion extension that allow you to work with Mercurial on top of SVN, converting all commits into Mercurial commits. I would not really recommend that though, especially if you’re a novice Mercurial user, the fundamental mismatch between SVN and Mercurial means that branching isn’t really possible if you want to push your changes back, you have to rebase all the time and you can very easily end up with data loss.
注意：
甚至可以用于不相关 URL（不同的存储库）。在一个存储库内合并只是一种约定和工作流程
不，
请参阅我的起始注释 - 您至少可以尝试存储库之间的本机 svn 合并
Note:
can be used even for unrelated URLs (different repos). Merge inside one repo is just a convention and workflow
No, always is transparent
See my starting note - you can at least try native svn merge between repos