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 回答