对于非常小的团队(一个开发人员),推荐的源代码控制系统是什么?
价格无所谓。客户会付费 :-)
我正在使用 C++ 中的 VS 2008 以及后来的 C# 和 WPF 开发 Vista32。为此设置一个额外的(物理)服务器对我来说似乎有点矫枉过正。
有什么意见吗?
26 回答
我会使用 Subversion(事实上我使用它)[更新:2014 年 7 月——我使用 Git——见答案的结尾]。SVN 是:
- 自由,
- 足够好(见下面的缺点),
- 简单的,
- 在 Windows(和 Linux 也一样)上运行良好,
- 很多人使用它,所以很容易获得帮助,
- 可以与大多数 IDE 集成,即Visual Studio(即ankhsvn或VisualSVN——更多信息)或Eclipse(即Subclipse——这里有人问过这个问题)。
我强烈推荐单独的机器到源代码控制服务器。充其量是在云端的某个地方。好处:
- 如果您的开发盒死机,您不会丢失源代码控制存储库。
- 您不必担心再维护一个盒子。
有些公司托管 SVN 存储库。
以下是各种操作系统的 SVN(客户端和服务器)包的链接。
SVN的缺点
我在 Windows 机器上使用 SVN 大约 5 年,发现 SVN 有一些缺点:)。
在大型存储库上速度很慢
SVN(或其客户端——TortoiseSVN)有一个很大的缺点——除非你有SSD驱动器,否则它在大型(数千个文件)存储库上(更新或提交时)速度非常慢。
合并可能很困难
许多人抱怨用 SVN 合并有多难。
我确实合并了大约 4 年(包括大约 2 年的 CVS - 这很糟糕,但可行)和大约 2 年的 SVN。
而且我个人认为这并不难——另一方面——在 CVS 中合并分支后,任何合并都很容易:)。
我每周合并一次大型存储库(实际上是两个存储库),并且很少遇到难以解决的冲突(大多数冲突是通过我使用的diff软件自动解决的)。
但是,如果您保留一些简单的规则,那么在几个开发人员合并的项目中应该根本不是问题:
- 经常合并更改,
- 避免同时在各个分支中积极开发。
2011 年 7 月添加
许多开发人员推荐分布式版本控制,例如Git或Mercurial。
从单个开发人员的角度来看,DVCS 与 SVN 相比只有几个重要的优势:
- DVCS 可以更快。
- 您可以提交到本地存储库而无需访问中央存储库。
- DVCS 是热门事物并且喜欢使用/学习(如果有人为您的学习付费)。
而且我不认为在单个开发人员的情况下合并是一个问题。
Joel Spolsky 写了关于 Mercurial 的教程,绝对值得一读。
因此,尽管 DVCS 有许多优点,但如果合并或速度不是问题,我会继续使用 SVN。
或者尝试 Mercurial,根据这个和这个SO questions,它在 Windows 上得到更好的支持(2011 年 7 月)。
2014 年 7 月添加
大约一年来,我将 Git(主要是 Git Bash)用于我的宠物项目(即解决欧拉问题),每个欧拉问题的本地分支都是非常好的功能——正如它被描述为 DVCS 的优势一样。
今天,Windows 上的 Git 工具比 2 年前或更多年前要好得多。您可以使用远程存储库(如 GitHub 或 ProjectLocker 和许多其他)将您的项目副本远离您的工作站,而无需额外的努力/金钱。
但是我只使用 GUI 客户端来查看差异(有时选择要提交的文件),所以最好不要害怕命令行——这真的很好。
所以从今天开始,我会选择 Git。
我也会推荐 Mercurial。它的命令集很像 Subversion 中的命令集,因此学习曲线并不陡峭。如前所述,它设计为在本地运行,但也很容易在计算机之间共享/合并更改,甚至只是将其推送到远程服务器进行备份。
它提供了优秀的工具,比如TortoiseHG,并且它有很好的 NetBeans 和 Eclipse 插件。它也可以在 Win32 上本地运行,因为它是用 Python 编写的。
如果您不想自己设置服务器(例如用于备份),可以使用免费的托管服务提供商;Mercurial Wiki上有一个完整的列表。
我肯定会推荐git
适用于大型和小型团队。唯一的缺点是较差的原生 Windows 支持。虽然它在 Cygwin 中对我来说很好用。还有一个本地 windows 端口。
它的一些好处:
- 对非线性工作流程的出色支持。它的分支和合并比例如 Subversion 好得多。
- 导航存储库的好工具
- 很好地处理大型项目。
- 如果不更改存储库的加密签名,则无法修改历史记录
- 凭借其非整体式设计,易于编写脚本。
有些人发现它有一个陡峭的学习曲线。但是一旦你理解了它,你几乎可以用它做任何你想做的事情。
去 subversion 和 tortoiseSVN,你不需要在服务器上设置它。
- 成本为零
- subversion 文档很棒而且阅读起来很有趣
- tortoiseSVN 是一个非常方便的客户端
Sourcegear 的 Vault是一个很好的选择,它在 SqlServer 上运行并且已经存在很多年了。我不会使用任何版本的 VSS(Visual Source Safe)。
Subversion 的进入门槛非常低。
TortoiseSVN是一个免费客户端,并集成到您的资源管理器中 - 即在鼠标右键菜单中。
存储库可以只是您 PC 或网络驱动器上某处的目录。备份只是意味着压缩这个目录
Visual Studio for Subversion 有一些插件,AnkSvn是我用过的一个,它是免费的并且很好地集成(即它会很聪明地移动和删除文件等)
Subversion 对开发人员来说是一个不错的选择。
更新:
自从这篇文章以来,我一直在使用 Mercurial。它是一个分布式SVN。“分布式”方面可能对单独的开发人员没有直接用处,但它更擅长合并并且速度更快。还有一个免费且不错的 Windows Explorer 扩展客户端 - Tortoise Hg。
因此,总而言之,如果您是那种会同时在多个分支上工作(做峰值等)的人,或者如果您同时在多台 PC 上工作并且希望完全离线访问这两个 PC 上的签入历史记录,那么Mercurial。如果您只想要简单的跟踪和经过充分验证且易于理解的解决方案,那么Subversion。
我很惊讶没有人提到Perforce。它对 2 人免费,速度极快,并且与 VS 集成。默认情况下,源服务器也有绑定。
除了源代码控制之外,完成循环并设置符号服务器和源服务器确实值得,这样您就可以对已发布的任何内容进行简单的调试(例如,不再搜索与二进制文件匹配的 pdb 或源代码) . 自 2005 年以来,源和符号服务器都是完全免费的,并且在 VS 中得到支持。
我使用Mercurial。它在我的 Vista 开发系统上独立运行,无需其他依赖项。我使用命令行,但也有TortoiseHG与 Explorer 集成。
两条评论:
- 还有其他工具可能更好地与 VS 集成。我认为 Subversion 有很好的 VS 插件。
- 单独服务器的好处是,它可以很好地备份您的所有工作,以防万一您的 HDD 死在您身上等,因此拥有一台服务器会打折。
编辑: @Slartibartfast - 如果您只想在单台机器上运行源代码控制,那么像 git 或 Mercurial 这样的分布式源代码控制工具是理想的,因为它们旨在在没有服务器开销的情况下在机器上运行完整的存储库。您永远不会将您的存储库连接到其他任何人的存储库以推送和拉取更改的事实并不意味着该工具不会正确。
您可以使用 SourceGear 的 Vault,它是 Visual Studio 源代码安全的替代工具。IDE 集成在 Visual Studio 中。
该工具对单用户免费。
更多信息: http: //www.sourcegear.com/vault/index.html
您的问题有两种可能的解决方案:集中式 VCS 或分布式 VCS (DVCS)。
像 Subversion 这样的集中式 VCS 将满足您提交和浏览日志的功能。它还使您能够将存储库安全地存储到另一台计算机上,这应该是您的主要目标之一,因为硬盘驱动器故障总是有可能发生的。然而,使用 Subversion,历史仍然只存在于中心位置,使其容易受到攻击,并且您声明您不想拥有另一台服务器。
Mercurial 和 Git 等分布式版本控制系统 (DVCS) 使您能够对存储库执行更复杂的操作。使用这两种工具,整个存储库都驻留在同一台计算机上,这使得备份和将存储库与另一台计算机(例如笔记本电脑)一起使用变得更加容易。虽然 Mercurial 起初可能看起来很复杂,但您在 subversion 中使用的操作与 Mercurial 几乎相同。因此,如果您已经了解 Subversion 并且以后可以轻松使用 Mercurial 的更高级功能,则无需额外开销即可开始使用。
您应该能够为您的 Mercurial 存储库找到在线存储库服务,使您能够轻松地进行备份并在有一天需要时进行协作。
我的推荐是 Mercurial 和 TortoiseHg。
源代码控制系统不在乎是否只有一个开发人员参与 :)
我建议您使用您以前使用过并喜欢的源代码控制系统。
如果您喜欢源代码控制系统的 vs 2008 集成,但我会选择TFS ,尽管我从未有过设置它的经验,但它不应该那么难。
另一种可能性是使用 svn(你会在 google 上找到一些服务器)并使用集成到 windows shell 中并且很好用的Tortoisesvn 。
许多帖子主张将存储库放在服务器上,因为它提供了冗余。我认为这对单个用户没有太大帮助。使用单独的服务器机器会增加很多复杂性,但不会带来太多冗余:如果您丢失了服务器机器,您的开发机器上仍然有当前资源,但您可能丢失了所有历史记录。如果定期备份该服务器,则将存储库放在服务器上确实有意义。为存储库使用外部托管服务可以提供存储冗余,但您受外部服务的支配,并且您需要互联网连接才能访问存储库。如果您使用外部主机,请经常备份您控制的存储库!
我个人推荐 TortoiseSVN 使用基于本地文件的存储库。只需确保定期将本地存储库备份到第二台机器或外部媒体(如 CD-ROM)。
我推荐两件事:
首先,另一台服务器——如果你的机器死了会发生什么?房子烧了?等等。从冗余的角度来看,将它放在另一台机器上是一个好主意。
第二个是什么:
如果您非常熟悉可视源(非)安全,请考虑 SourceGearVault。它非常好,非常快,并且大大改进了 VSS 的“克隆”(即从用户 POV 以相同的方式工作,而不是在引擎盖下)。需要 SQL 服务器和 Windows(它是 .NET + SQL 服务器)。1 位用户免费。
你不是,那么我建议你做两件事之一:
首先,获取 VisualSVN。很棒,与 VS2008 配合得非常好。其次,如果您必须在本地运行它,请获取 VisualSVN 服务器(免费!)。确保你有一个好的备份计划。在 XP/2003/2008/Vista 等上运行。它只是 Apache + SVN,在引擎盖下,所以它只是为您节省了设置 - 我花了 5 分钟安装并运行它。
或者,我更喜欢这个:
去像 Unfuddle、Dreamhost 等的地方,并获得 SVN 的托管。它是私密的,速度很快,最重要的是 - 它是离线的。我的dreamhsot 帐户,拥有500GB 的存储空间和1-2TB 的传输/月费用约为6 美元/月!还有其他做 SVN 托管 + 错误跟踪等。环顾四周。
但是,是的 - SVN 是 schizzzznit。你可以创建一个本地存储库,但我喜欢拥有一个远程备份服务器。
TFS 是总的,对于 1 个开发人员(或 <5 个 IMO)来说完全是多余的
我意识到成本不是问题,但一个不错的免费解决方案是不涉及签入和签出,通过这样做您将立即获得版本控制和备份,这是一个单一的主要功能开发者系统会提供。
Bazaar是一个很好的版本控制系统。我喜欢将它用于我的 linux 配置,因为您不需要创建单独的 repo。
不久前,我写了一篇关于仅与一个开发人员一起使用 SVN 的操作方法博客文章。我称之为单服务源代码控制
好吧,首先,你不需要分布式的 :) 我不确定这个物理部分是什么意思,因为你可以把 svn 服务器放在你自己的机器上,不会有什么麻烦。
另一方面,NetBeans 具有记录文件所有本地更改的本地历史模块。如果 Visual Studio 有类似的东西,也许这样的东西对你来说就足够了。
我会推荐 Subversion,因为它适用于单个开发人员,并且我假设您没有进行复杂的合并和大量的日志/历史检查。
似乎很多人都在使用http://svnrepository.com/进行托管。如果您以后需要它,它会随 Trac 甚至 Git 一起提供。
这里有一些很好的答案。
我想重申使用单独的计算机来托管源代码控制服务器的建议,尽管它不必是专用计算机。它可能是您的 Windows Home Server 机器,或者您已经在运行的其他服务器。或者它可能是托管在其他服务器上的虚拟机。无论如何,只需将其与您编写代码的机器分开即可。
我还想建议您为您的服务器制定良好的备份规则。至少每晚都有点东西;如果可以的话,每小时一次。备份到专用设备(如外部硬盘驱动器)或异地设备(您堂兄在另一个州的家中的服务器)或云中(Amazon S3)。请记住,您的源代码是您的关键资产;搞定此事!
我已经在Bazaar工作了几个星期,非常喜欢它。我是一名 linux 开发人员,所以对 Tortois 不太了解,但如果你喜欢它,你应该知道有一个Tortoisbzr
毫无疑问,我会使用 git,而且我相信git magic中暗示或描述了单个开发人员想要使用 git 的许多原因
我不明白为什么您的一位开发人员会更改源代码控制问题上的任何内容。我会遵循相同的系统(事实上我在个人项目中也是如此)。在这些情况下,我使用wush.net(svn 和 trac)。设置速度很快,不需要您自己做或知道任何服务器问题。我建议你使用这样的东西。
我建议使用颠覆。许多人建议使用单独的盒子作为服务器,以防您的开发机器死机。当 SVN 服务器死机时会发生什么?这里的答案是,无论您选择在哪里运行服务器,请确保您始终进行频繁的备份,可能每天自动备份到一些辅助的、最好是异地机器。
我也将 Perforce 用于我自己的个人资料,主要是因为我们在工作中使用它。它也有 emacs 绑定,因此您可以在 emacs 中同步、签入或签出等。
我最近把我的工作室从 Subversion 搬到了 Perforce,并在我的博客上放了一些关于它的笔记,有点像事后总结。希望它有用。