我应该看看Subversion之外的版本控制系统吗？

Question

在过去的一年里，我已经沉迷于颠覆。我是唯一的开发人员，我也参与了一些自己的项目。使用SVN，它可以很容易地管理所有内容 - 并且因为它通过HTTPS托管在在线服务器上，所以我可以从任何地方访问我的代码。它也非常适合将代码部署到我们的生产/开发服务器。

我的观点是它完成了我需要做的所有事情并且从未让我失望过。

有什么更好的吗？我是否错过了其他可以用来让我的生活更轻松的产品的功能？我总是在使用最好的软件，并且没有问题迁移到新技术。

我听说过GIT，并做过一些研究。我打算尝试一下，但是当我搞砸了它时，还有另外一个被认为是“行业标准”的其他源控制系统，他们做的事情比SVN好吗？

Answer 1

Git，Mercurial和Bazaar是分布式控制系统，其运行的理念是您并不总是连接到网络，并且不需要存储库的一个中央版本。

如果您正在进行大量独立工作，有时也称为“飞行模式”，就像您在飞机上无法承诺一样，请看看Bazaar。我发现比Git或Mercurial更容易适应。

如果你一直在做与网络相关的工作，并且你是唯一的开发人员，那么你可能会坚持使用Subversion。

另外，请考虑keeping your home directory in Subversion的价值。

Answer 2

<强>水银

我主要使用CVS和SVN，快乐和内容，然后我开始研究分布式源代码控制，因为有很多关于DSVC的大惊小怪。在使用DSVC后，我注意到我的开发风格发生了变化，我变得更加流畅和适应性强。允许我无痛地合并回主干或实验分支。

• Mercurial可以从单人乐队扩展到巨大的即OpenJDK，没有太多头痛。
• Mercurial很快，可能没有GIT那么快，但它仍然很快
• Mercurial Queues是管理补丁的绝佳方式。以润滑的光照速度。
• 它可以在不同的操作系统上运行，兼容性很好，因为它基于python。
• 学习曲线低于GIT，经过一些文档阅读后你得到了基本的东西（http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/）
• hg允许（许多DSVC）您使用hg-svn和hgsubversion与公司SVN Source控件进行交互，这是一个带有允许和检出的美妙扩展，但尚未推送或提交功能
• 您也可以设置HTTP服务器运行push and pull via SSH
• 还有一个非常巧妙的选择，即与你的编码伙伴聚在一起，只需启动HTTP服务器就可以通过localhost运行它，你的配偶可以在你进行代码冲刺时推拉。
• 您还可以通过此HTTP页面查看项目的当前状态。
• 最后在这里查看简单命令（http://edong.net/2008v1/docs/dongwoo-Hg-PDF.pdf）
的简要说明

<强> GIT中

• 尝试过，它对svn的支持比mercurial更好。但是因为hgsubversion正在升级并成为git svn的竞争。

Git很酷，但您需要不断维护源代码depo并重新打包。 由于它包含许多bash脚本，因此无法在Windows上运行。 但它速度极快，有许多功能供您使用。实际上，功能的数量可能是一个缺点。

<强> BZR

• 从未尝试过

自从我开始使用HG以来，我一直回头看。

Answer 3

我个人会留下Subversion。从专业角度来看，我看到更多的工作要求（并知道）Subversion与GIT的比较。还有很多围绕Subversion构建的开源和免费软件工具，更不用说Subversion庞大的社区了。

源代码控制并不总是关于最新和最好的，但更多的是关于尝试和真实的事情。

Answer 4

改变的最佳理由是必要性。但是，听起来似乎没有必要改变。你是一个“军队之一”，所以大多数强大的功能都不适用于你的情况。是的，人们会在这方面与我争论，但他们会推动这个功能或那个你真正不需要的功能。时间就是一切，如果将来你的需求发生变化，那就改变你的解决方案。

对于问题空间总会有更好或不同的解决方案，在这种情况下是源代码控制，但是您应该平衡个人开发，流程/实践改进和交付工作产品。您可以了解有关源代码控制的不同解决方案/应用程序的更多信息，以扩展您的知识，以便及时了解切换解决方案的时间，但坚持现在可以使用的方法。

Answer 5

以下是3 reasons to switch to git from Subversion（来自MarkMcB）：

• 无限，简单，非基于文件系统的本地分支机构
• 存放临时工作
• 公开提交前的协作

（阅读链接文章以获得完整的解释，并直接比较如何在git和Subversion中完成三件事。）

Answer 6

我个人也会留下Subversion， 有什么更好的吗？

Subversion是一个很棒的版本控制系统，你很满意它，所以如果你看得更远，我可以建议你获得一些关于Continuous Integration的信息，有很多工具可以帮助你您可以进行自动构建，使构建自我测试，检查每个提交的完整性等等......

Answer 7

Mercurial也值得考虑;分支更友好，它可以在没有网络连接的情况下工作。在从SVN搬到Mercurial之前，我从未认真地尝试将工作分成分支。

我非常想念的一件事是TortoiseSVN;有一个相似的（TortoiseHg）非常好，但它只是不一样..

无论如何，从SVN创建一个Mercurial仓库非常容易......试一试，看看它是否适合你。

Answer 8

规则编号1：“永远不要更改正在运行的系统”

此外，由于有许多闪亮的新解决方案（对于您没有的问题，因为您单独工作），您应该考虑切换到新VCS的成本： 将subversion导入Mercurial / git并不是一件容易的事情

没有工具（AFAIK），它使用dumpformat导入svn repos。因此，如果您不使用dumpformat，您将坚持从svn签出所有分支/标签并手动/通过脚本将其添加到git / BZR / Mercurial

所以我不知道你的回购有多大（我的回购范围从20 MB到24GB），但是需要很长时间来查看整个回购甚至是小项目很多标签会占用很多硬盘空间。

其他问题是迁移完成后的时间，您无法继续工作。

Answer 9

为了获得最好的工具，我在不断调查的问题上就像你一样。

我尝试过SVN for SOLO的工作，有人推荐我Mercurial（hg）。现在我做关于它的主题演讲。 它比Windows中的git更友好。我现在认为“为什么svn会像标签之类的简单任务一样复杂化”。 SVN不知道标签是什么。对于SVN，标签是副本。 在mercurial中，标记是修订的别名。这有多复杂？

表演这是另一个问题。在Mercurial你的回购它在你的本地机器上。所以它对于日志，差异或历史来说非常快。

虽然我对您的回购网站版本支持mercurial的服务器一无所知。

Answer 10

如果SVN满足您的所有需求，那么我看不出改变的原因。 如果好奇心是您寻求不同源代码控制的驱动因素，那么我建议您阅读git或其他分布式scm解决方案，并尝试确定是否值得投资以便切换（我怀疑它是否在您的情况下）。

Answer 11

有一句古老的洋基谚语。

如果没有损坏，请不要修复它。

Answer 12

即使您实际上并未使用分布式工作流，也绝对值得研究“分布式”VC。能够拥有私有分支并控制您的本地提交是值得学习git的努力。我一直主要使用git-svn（其他团队成员使用常规的SVN客户端，所以我们有一个正常的，集中的工作流程），它的工作非常完美。