28

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

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

有更好的吗？我是否缺少其他产品中的某些功能，可以用来让我的生活更轻松？我一直都在使用最好的软件，并且在迁移到新技术方面没有问题。

我听说过 GIT 并做了一些研究。我打算尝试一下，但是当我对此感到困惑时，是否还有其他被认为是“行业标准”的源代码控制系统，它们是否比 SVN 做得更好？

4

12 回答 12

27

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

如果您正在做很多独立的工作，有时称为“飞行模式”，例如您在飞机上并且无法提交，请查看 Bazaar。我发现它比 Git 或 Mercurial 更容易适应。

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

另外，请考虑将主目录保留在 Subversion 中的价值。

于 2008-10-22T03:41:07.470 回答
16

水银

我主要用的是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 源代码控制进行交互，这是一个带有允许和签出功能的精彩扩展，但还没有推送或提交功能
  • 你也可以设置一个 HTTP 服务器通过 SSH 运行推送和拉取
  • 还可以与您的编码伙伴聚在一起，只需启动 HTTP 服务器在 localhost 上运行它，您的伙伴可以在您进行代码冲刺时进行推送和拉取。
  • 您还可以通过此 HTTP 页面查看项目的当前状态。
  • 最后在这里查看简单命令的简要说明（http://edong.net/2008v1/docs/dongwoo-Hg-PDF.pdf）

吉特

  • 试过了，它对svn的支持比mercurial好。但由于 hgsubversion 正在兴起并成为 git svn 的竞争者。

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

BZR

  • 从未尝试过

自从我开始使用 HG 以来，我没有回头

于 2008-10-22T05:20:12.667 回答
10

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

源代码控制并不总是关于最新和最伟大的，而是更多关于经过尝试和真实的东西。

于 2008-10-22T03:40:38.673 回答
10

改变的最好理由是必要性。但是，听起来没有真正需要改变。您是“一体之军”，因此大多数强大的功能不适用于您的情况。是的，人们会在这个问题上与我争论，但是他们会推动这个功能或者你很可能真的不需要的那个功能。时间就是一切，如果将来您的需求发生变化，请更改您的解决方案。

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

于 2008-10-22T04:49:32.887 回答
9

以下是从 Subversion （来自 MarkMcB）切换到 git 的 3 个原因：

  • 无尽的、简单的、非基于文件系统的本地分支
  • 暂存临时工作
  • 公开提交之前的协作

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

于 2008-10-22T03:50:56.700 回答
5

我个人也会继续使用 Subversion， 还有什么更好的吗？

Subversion 是一个很棒的版本控制系统，你对它很满意，所以如果你想进一步了解，我可以建议你获取一些关于持续集成的信息，那里有很多工具可以帮助你进行自动构建，让您的构建进行自我测试，检查每个提交的完整性，等等...

于 2008-10-22T04:19:33.180 回答
3

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

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

无论如何，从 SVN 创建 Mercurial 存储库非常简单……试一试，看看它是否适合您。

于 2008-10-22T03:51:07.810 回答
2

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

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

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

所以我不知道你的仓库有多大（我的仓库从 20 MB 到 24GB 不等），但是检查整个仓库需要很长时间，即使是带有很多标签的小项目也会吃掉很多硬盘空间。

另一个问题是在完成迁移之前您无法继续工作。

于 2008-10-22T17:31:01.600 回答
1

有一句古老的洋基谚语。

如果它没有坏，就不要修理它。

于 2008-11-01T16:26:01.263 回答
1

我和你一样，为了获得最好的工具而不断调查。

我尝试使用 SVN 进行 SOLO 工作，有人推荐我 Mercurial (hg)。现在我做关于它的主题演讲。它比 windows 中的 git 更友好。我现在想“为什么 svn 会使标签之类的简单任务变得复杂”。SVN 不知道标签是什么。对于 SVN，标签是一个副本。在 mercurial 中，标签是修订版的别名。能有多复杂？

性能是另一个问题。在 Mercurial 中，您的存储库位于您的本地计算机中。因此，对于日志、差异或历史记录来说，它的速度非常快。

尽管我对支持 mercurial 以获取您的 repo 在线版本的服务器一无所知。

于 2008-11-19T01:10:18.150 回答
1

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

于 2009-06-18T09:12:44.233 回答
0

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

于 2008-11-01T16:08:07.900 回答