从 ClearCase 到 Mercurial，再到现在的 Subversion。我应该担心吗？
当我开始现在的工作时，我在 ClearCase 的地狱里度过了一年。一切都有点像冬天的魔多，只是没有笑声。然后我们开始使用 Mercurial。大约一天半之内，云彩散去，阳光普照，鸟儿开始歌唱——或者那些是天使吗？我问这是不是天堂，凯文·科斯特纳说：“不，这是爱荷华州 Mercurial。”
现在我要跳槽到一家使用 Subversion 的公司。我应该害怕吗？我听说过有关 Subversion 的好消息，它比 Vault（我讨厌它）好，而且比 ClearCase 好得多。我已经阅读了这里关于 SO 的许多讨论，但我不断回到 Joel Spolsky 的隐式声明，即如果我使用 Subversion 我会遭受脑损伤。我已经做好了遭受一点脑损伤的准备，但是有人对如何最大限度地减少灰质的冲击和损失有建议吗？
When I started my current job, I spent a year in ClearCase hell. Everything was kind of like Mordor in winter, only without the laughs. Then we started using Mercurial. Within about a day and a half the clouds moved away, the sun shone, birds started singing — or were those angels? I asked if this was heaven, and Kevin Costner said "No, it's Iowa Mercurial."
Now I'm moving to a company that uses Subversion. Should I be afraid? I've heard good things about Subversion, that it's better than Vault (which I hated) and way better than ClearCase. I've read many of the discussions here on SO, but I keep coming back to Joel Spolsky's implicit declaration that if I use Subversion I will incur brain damage. I'm prepared for a little bit of brain damage, but does anyone have advice on how to minimize the shock and loss of graymatter?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
向后移动将会使 Subversion 看起来有些原始，但它通常易于使用且健壮，即使功能不那么丰富。我认为从像 Mercurial 这样的现代 DVCS 迁移到 Subversion（“CVS 做得‘正确’”）之间的最大区别是 Subversion 使用文件系统来类比一切：
这些操作实际上并不是标签或分支，但“标签”和“分支”目录按照惯例是这样命名的。
您还必须更加小心，因为提交任何更改都会将其推送到主存储库以供每个人查看。意外的提交可能会破坏每个人的“主干”，导致不愉快的情况。
另外，当您必须通过网络完成所有操作时，请做好操作缓慢的准备。
Moving backwards will make Subversion seem somewhat primitive, but it's generally easy to use and robust, if not as feature-ful. I think the biggest difference between moving from a modern DVCS like Mercurial to Subversion ("CVS done 'right'") is that Subversion uses the file system as an analogy for everything:
These operations aren't really tags or branches, but the "tags" and "branches" directories are named that by convention.
You also have to be more careful, because committing any changes will push it to the main repo for everybody to see. An accidental commit can break "trunk" for everybody, leading to unhappy situations.
Also, be prepared for slow operations when you have to do everything over the network.
很像clearcase - svn 的很多乐趣或痛苦不是工具本身，而是实现（或缺乏）。开箱即用的透明盒子实际上无法使用，有一群聪明的人管理它并设置整个过程，它从毫无价值到疯狂昂贵和轻微的创伤。
你在 svn 上会没事的。你会想念 hg，但应该能够轻松完成工作。如果你不是 - 责怪那些主持节目的人，而不是工具。
一些 svn 管理员使用钩子来阻止不支持 svn:mergeinfo 属性的客户端提交，git 和 hg 连接器在这些实现中不起作用。
并不是说 mergeinfo 有那么有用……如果你不能指望它在那里，它就完全没有价值。
Much like clearcase - a lot of the joy or pain of svn isn't the tool itself but rather the implementation (or lack of). out of the box clearcase is virtually unusable, with an army of smart people administrating it and setting up the whole process it goes from worthless to just crazy expensive and mildly traumatic.
you'll be fine on svn. You'll miss hg, but should be able to get your work done with minimal fuss. If you aren't - blame the guys running the show, not the tool.
Some svn admins use a hook to prevent commits from clients that don't support the svn:mergeinfo property, the git and hg connectors wouldn't work in those implementations.
Not that mergeinfo is that useful... it's totally worthless if you cannot count on it to be there.
经过多年使用 Subversion 和现在使用 Mercurial，对我来说主要的区别是分支。我不想回到 Subversion，我会想念它。
但毕竟你可以在本地磁盘上使用 Mercurial（甚至在 Subversion 存储库的签出目录中），也许在不久的将来你可以说服合适的人，然后阳光会再次普照......
After years of working with Subversion and now with Mercurial, the main difference for me is branching. I wouldn't like to go back to Subversion, I would miss it.
But after all you can use Mercurial on your local disc (even in the directory which is the checkout of the Subversion repository), maybe in the near future you can convince the right person and then the sun will shine again...
尝试 hgsubversion 作为客户端，这至少可以让你做你自己的实验分支、本地提交、搁置和其他一些不错的 Hg 功能。
然而，有时我在导入大型存储库时遇到困难，在这种情况下我会切换到 hgsvn 并在 subversion 工作副本上使用“hg-importsvn --local-only”。它需要一个 svn 客户端。我推荐Slik SVN。
这两个工具都允许您回推 svn 存储库，但它们的操作方式有所不同。
我必须承认，尽管我更喜欢 hgsubversion 的概念，但我更频繁地使用 hgsvn。导入过程还不够可靠。
Try hgsubversion as a client, that will at least allow you to do your own experimental branches, local commits, shelve and a couple other nice Hg features.
Sometimes I've had difficulties with imports of large repositories, however, in which case I switch to hgsvn and use "hg-importsvn --local-only" on a subversion working copy. It requires an svn client. I recommend Slik SVN.
Both tools allow you to push back to the svn repo but they differ in how they operate.
I have to admit, I use hgsvn more often even though I like the concept of hgsubversion better. The import process just isn't reliable enough yet.
对于哪个更好，分布式源版本控制 (DSVC) 世界 (git/mercurial/et al) 和 CSVC（集中式...）之间存在意见分歧。
有些人喜欢经常在本地签入 DSVC 方法，但只将“工作”代码推送到中央/主存储库。
有些像 CSVC 方法的所有提交都立即对每个人可见，但中央存储库中的代码可能并不总是有效。
最终，选择是个人的，我不会对此太激动，尽管我会说我认为 DSVC 更适合较大的群体，并且它可能也更适合持续集成设置。但是，正如您始终可以用任何语言编写 COBOL 一样，通过源代码控制，您也可以使其按照您想要的方式（集中式或分布式）工作。
您更关心的是公司文化是什么？他们是否接受 svn repo 可以随时被破坏，或者他们是否要求 svn repo 始终工作？在我看来，这是关于你是否会保持理智的最大界限。
There is a difference of opinion between the Distributed Source Version Control (DSVC) world (git/mercurial/et al) and the CSVC (Centralised...) as to which is better.
Some like DSVC method of check in locally often, but only ever push "working" code to the central/master repository.
Some like the CSVC method of all commits are immediately visible to everyone, but the code in the central repository might not always work.
Ultimately, the choice is personal, and I would not get too worked up about it, although I will say that I think that DSVC works better for larger groups, and it probably also works better for a continuous integration setup. But, just as you can always write COBOL in any language, so too with source control can you make it work the way that you want, centralised or distributed.
What is more of a concern for you is what is the company culture? Do they accept the svn repo can be broken at any time, or do they demand that the svn repo always be working? That is the biggest delineator, IMO, as to whether or not you will preserve your sanity.
有一个 svn-hg 连接器。
我在当前的公司使用 Clearcase，并将细粒度的提交保存在 hg 存储库中。
There is a svn-hg connector.
I use Clearcase at my current company and keep my fine-grained commits in a hg repo.