关于svn：Git / Mercurial / Bazaar的受欢迎程度与推荐


Popularity of Git/Mercurial/Bazaar vs. which to recommend

按照这三个分布式版本控制系统在这个站点上的问题的数量来看，Git似乎也是

  • 更受欢迎，或者
  • 更困难(因此需要更多的问题)，或
  • 具有更多功能(因此需要更多问题)。

    • 或者可能是三者的结合。(假设此网站的人气相当于总体人气。)以下是数字：

    enter image description here。氧化镁

    有三种相互竞争但基本上相当的开源产品可供选择，这并不完全令人满意。就我个人而言，我使用Git，我和另外两个没问题。但是，当涉及到推荐一个系统而不是其他系统时，我想问：我们能安全地开始推荐一个吗？

    2009年年中的评论：最近颠覆运动的历史流行程度明显反映在问题的数量上，这表明在变化莫测的市场或集市上，至少有一小部分规模向Git倾斜。

    2010年年中的评论：看看那些相对增加的巨幅反复无常的数字。显然，只有两个数据点不足以显示一种趋势，但看起来Git和Subversion基本上是根深蒂固的，Mercurial已经看到了大量增长，Bazaar仍然相对平静。

    简要评论，2011年年中：我们可以叫吉特为赢家吗？:)不，我接受这样一种观点，即问题的数量不等于受欢迎程度。不过，数字确实很强劲。

    复制上述绘图的代码：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    import datetime as dt
    import matplotlib.pyplot as plt


    dates = [
       "01/06/2009",
       "01/07/2010",
       "01/07/2011",
       "01/07/2012",
       "01/07/2013",
       "01/07/2014",
       "01/07/2015",
       "01/07/2016",
       "01/06/2017",
       "28/08/2018",
       "27/05/2019"
    ]
    x = [dt.datetime.strptime(d,"%d/%m/%Y").date() for d in dates]

    git = [726, 3725, 9225, 17523, 27862, 41478, 55315, 71056, 86958, 102362, 110970]
    svn = [2353, 5323, 9028, 12687, 15587, 18846, 21209, 23037, 24692, 25525, 25868]
    mercurial = [169, 1120, 2765, 4221, 5230, 6030, 6651, 7134, 7524, 7765, 7894]
    bazaar = [50, 159, 252, 351, 425, 483, 506, 525, 534, 539, 544]

    ax = plt.gca()

    ax.grid()
    plt.plot(x, git, label="[git]")
    plt.plot(x, svn, label="[svn]")
    plt.plot(x, mercurial, label="[mercurial]")
    plt.plot(x, bazaar, label="[bazaar]")
    plt.gcf().autofmt_xdate()
    plt.ylabel("number of tags on stackoverflow")
    plt.ylim(0)

    plt.legend()

    # plt.show()
    plt.savefig("comparison.png", transparent=True, bbox_inches="tight")
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    import datetime as dt
    import matplotlib.pyplot as plt


    dates = [
       "01/06/2009",
       "01/07/2010",
       "01/07/2011",
       "01/07/2012",
       "01/07/2013",
       "01/07/2014",
       "01/07/2015",
       "01/07/2016",
       "01/06/2017",
       "28/08/2018",
       "27/05/2019"
    ]
    x = [dt.datetime.strptime(d,"%d/%m/%Y").date() for d in dates]

    git = [726, 3725, 9225, 17523, 27862, 41478, 55315, 71056, 86958, 102362, 110970]
    svn = [2353, 5323, 9028, 12687, 15587, 18846, 21209, 23037, 24692, 25525, 25868]
    mrc = [169, 1120, 2765, 4221, 5230, 6030, 6651, 7134, 7524, 7765, 7894]
    bzr = [50, 159, 252, 351, 425, 483, 506, 525, 534, 539, 544]

    n = len(dates)
    intervals = [x[i+1] - x[i] for i in range(n-1)]
    git_per_day = [(git[i+1] - git[i]) / intervals[i].days for i in range(n-1)]
    svn_per_day = [(svn[i+1] - svn[i]) / intervals[i].days for i in range(n-1)]
    mrc_per_day = [(mrc[i+1] - mrc[i]) / intervals[i].days for i in range(n-1)]
    bzr_per_day = [(bzr[i+1] - bzr[i]) / intervals[i].days for i in range(n-1)]

    ii = [0] + [val for val in range(1, n-1) for _ in (0, 1)] + [n-1]
    jj = [val for val in range(n-1) for _ in (0, 1)]

    ax = plt.gca()
    ax.grid()

    plt.plot([x[i] for i in ii], [git_per_day[j] for j in jj], label="[git]")
    plt.plot([x[i] for i in ii], [svn_per_day[j] for j in jj], label="[svn]")
    plt.plot([x[i] for i in ii], [mrc_per_day[j] for j in jj], label="[mercurial]")
    plt.plot([x[i] for i in ii], [bzr_per_day[j] for j in jj], label="[bazaar]")

    plt.gcf().autofmt_xdate()
    plt.ylabel("average daily tags on stackoverflow")
    plt.legend()
    plt.ylim(0)

    # plt.show()
    plt.savefig("comparison-daily.png", transparent=True, bbox_inches="tight")

    号

    相关讨论

    • 您可以在这里查看git、mercurial和bazaar之间的全面比较：techtatava.com/2010/09/git-mercurial-and-bazaar-a-comparison
    • 由于现在是2011年7月，可能正在进行更新。BZR网站上提供了用户总数的最新比较。
    • 我同意问题标签计数不等于流行程度，事实上可能是反相关的。相反，问题计数与每个VCS系统的堆栈溢出用户问题直接相关。
    • 以下是每个VCS(以及所有其他Ubuntu软件包)的常规用户数：popcon.ubuntu.com/by inst bzr似乎有两倍于git的活跃用户群，至少在ubuntu linux上是这样，其中bzr是默认的开发协作工具。
    • 有人应该提出一个关于meta的好问题。SO团队可以访问有关这方面的硬数据，比如有多少人问过vs标签vs答案等。也许这些数据在数据库的著名XML转储中？
    • 如果开源世界总体上代表了VCS的使用，那么检查各种系统流行程度的另一种方法是查看Ohloh对VCS使用情况的分析，该分析涵盖了近60000个项目。有这样一个时间安排真是太好了。但我看不到。
    • 多亏了那些帮助保持数据活力的人！尽管这个问题已经结束，我仍然认为这是一个有趣的方式来看看这些VCS是如何增长的。

    2011年11月更新：

    Git现在比2009年成熟得多：

    • 现在支持智能HTTP，这意味着您可以向客户机提供用于拉/克隆和推送的HTTPS协议，并且具有与LDAP接口的身份验证(对于企业中的用户很重要)
    • Gitolite现在有了一个成熟的授权层，这意味着您可以为"机密"存储库提供隔离(同样，对于大公司很重要)。
    • Windows的支持在2009年就已经存在了，现在仍然很强大，TortoiseGit也相当稳定。
    • 与类似于IDE的Eclipse的集成正在进行中(大多数Eclipse项目现在都在Github上)

    但是，在集中环境中安装Git并不容易：参见"分布式版本控制系统和企业-一个好的组合？"

    有一点经常被忽略：

    它们的性质不同。

    • SVN是一个修订系统(它只通过便宜的拷贝存储分支和标签！合并支持不是很有效)，它是集中的。
    • Mercurial或Bazaar是文件VCS(它们存储文件版本)，并且是分布式的。ArneBabenhauserheide通过指出Mercurial的历史模型跟踪内容更改来修正Mercurial的这一点，并在存储层中重新使用文件路径来优化文件系统访问。
    • Git是一个内容VCS(它存储内容增量，而不是文件本身：两个内容相同的文件只存储一次)。

    这意味着：

    • 如果您有一个简单的合并工作流，在单个开发位置，请使用SVN。
    • 如果您有几个开发位置，分布式VCS更适合。
    • 如果您有一个复杂的合并工作流程，那么任何现代的VCS都比那些多年来一直努力将合并信息保持在正确位置的SVN要好。然后取决于工具(例如，Mercurial支持更高级的Windows)
    • 如果您主要使用文本文件，而不是太大的二进制文件，那么Git非常优秀，前提是您了解它的限制。
    相关讨论

    • 我认为Git和Mercurial之间的差别并没有你想象的那么大。如果隐式内容跟踪在git中工作得很好，那么为什么有git mv命令呢？kernel.org/pub/software/scm/git/docs/git-mv.html文件
    • @wcoenen:mercurial以revlog(seleric.com/mercurial/wiki/revlog)为核心，将文件链接到其历史记录。这是GitBlob的基本区别。但不确定你要用Git MV去哪里。它涉及Git索引(要提交的内容集合)，而不是Mercurial"Working Directory"及其要提交的"dirstate"(列出更改集——文件的更改集)。它们可能有相同的外部行为，它们的内部机制确实不同。
    • @VONC：为什么Git跟踪文件的内容而不是文件本身很重要？考虑到像hg git(hggit.github.com)这样提供Mercurial和Git之间全面往返的工具，我认为很明显它们在表达能力上是等效的。
    • @马丁："重要"？虽然我没有说"重要"，但它实际上对Git的设计方式很重要(thread.gmane.org/gmane.comp.version control.git/27/focus=217)。真实的DAG历史(没有为文件保留线性历史)。工作流有点不同(另请参见rg03.wordpress.com/2009/04/07/mercurial-vs-git)
    • @马丁："我是丹麦奥尔胡斯大学的博士生，也是Mercurial项目的开发人员。"请考虑我并没有试图假装一个人比另一个人"更好"；正如这篇博客中所说："Git vs.Mercurial:请放松"(importantshock.wordpress.com/2008/08/07/Git-vs-Mercurial)
    • @VONC：我认为你做这个列表是为了强调基于文件和基于内容的系统之间的区别(对于用户来说)是很重要的。这就是我问的原因。除此之外，我同意人们应该放松，Mercurial和Git都是强大的系统——你链接到一些好的博客来证明这一点。
    • @VONC：你的回答很好，但当你回答马丁："我是一名博士生……"时，我迷路了。但当你开始说你不想假装一个比另一个"更好"时，我找到了我的方法。
    • @我指的是马丁的个人资料，当时他是一名博士生。从那以后，他显然更新了个人资料；)
    • 说mercurial tracks文件不正确。Mercurial的存储系统使用基于文件的结构来提高磁盘使用效率，但是概念系统是基于内容构建的：简单的差异。想象一下，我将向Git添加一个备用存储格式，它存储文件中的更改。那么Git是基于文件的吗(对接口没有更改)？请参阅hg wiki以获取参考：mercurial.selenic.com/wiki/gitconcepts history_model
    • @阿内巴本豪塞海德：好的，我已经在答案中包括了你的参考资料。
    • @VONC：谢谢！尽管您可能只是想预先声明mercurial和git都跟踪内容来解决这个问题。你的回答的主要问题是混淆了风投的轨迹以及他们如何存储这些轨迹。Mercurial将更改存储在文件中，文件名为工作目录。但它跟踪变化集。存储模型是从历史模型中抽象出来的，因为这样可以从文件系统优化中获益。参见hgbook.red bean.com/read/behind-the-scenes.html_(避免寻找)和mercurial.selenic.com/wiki/&hellip；
    • @VONC：当您克隆Git repo和Hg repo时，请尝试监听(非SSD)磁盘。在Git的例子中，我听到我的磁盘被恶意黑客攻击，而使用Mercurial，它只会平稳地存储更改。我认为这是优化文件系统访问的优势。
    • GitHub之所以受欢迎，唯一的原因就是GitHub。=)
    • @我觉得你误解了。它与明确的内容跟踪毫无关系。从字面上看，它是mv的简写，然后是git-rm的旧名称，以及"git"的新名称。

    Going by the number of questions on this site for these three distributed version control systems, it seems like Git either

  • is more popular, or
  • is more difficult (hence requiring more questions), or
  • has more features (hence requiring more questions).

    • 号

  • 关于SCM的流行性——请参见下面的stackoverflow问题：对于免费的rcs/scm/vcs系统，有没有可用的流行性/使用统计数据？在这里，我们有一些问题，比如要为特定类型的项目使用哪一组忽略文件，这些文件是不可知的，但是要求使用git(并使用"git"标记)，因为提出问题的人使用它。

  • 关于Git的难度更大(因此对So有更多的疑问)——当然Git的学习曲线更陡。它还使用了一些(相当)独特的概念，比如临时区域(索引)，或者所有的分支都是相等的，它们负责它的功能，但一开始可能很难正确地进行(特别是如果一个分支来自其他的SCM)。此外，GitUI并不完全一致(尽管它会变得更好)，因为它是成长的，而不是开发出来的；这是它的强大功能，但可能导致用户界面不理想。

  • 关于Git有更多的特性——您必须检查有多少这样的问题是关于Git的高级/不常见特性的。但是，您应该知道，开放源码项目相互借用思想，或者独立开发类似的功能：一个例子是通过将提交的历史分为(搜索)两部分来发现bug，这引入了bug，这个bug(据我所知)是在Git中首先开发的，然后在Bazaar中作为插件实现的，并且是第一个扩展。目前是Mercurial的核心功能。另一种方法是交互选择要提交的变更片段，受DARC行为的启发。另一个可能是Git的捆绑概念，借鉴了Mercurial的类似概念。

  • 另一个可能的来源更多的所以问题可能是缺乏良好的文件…尽管现在Git用户手册(与Git一起分发)和Git社区手册(在Git主页上找到)的使用情况有所改善。不过，还有一个持久的模因，Git的文档比，比方说，使用Subversion(也称为Svnbook)和Mercurial:The Determinal Guide(也称为Hg Book)进行版本控制的Subversion更糟糕。有时，人们在询问StackOverflow问题之前不会阅读文档。

    • It's not entirely satisfactory having three competing yet largely equivalent open source products to choose from. Personally I use Git and I'm fine with the other two. But when it comes to recommending one system over the others, I'd like to ask: can we start recommending one safely yet?

    号

    好吧，Git和Mercurial几乎是在同一时间独立开发的，作为对Linux内核开发人员使用的BitKeeper的免费许可证终止的响应，作为它的替代。颠覆作为集中式的单片机是不可能的，核心对合并跟踪缺乏支持，这使得它完全不适合Linux内核的大分布式开发模式。集市可能太慢了(至少在那时)，有点集中(我猜)。

    Git是更强大的(在我看来)，水星是更简单的(在人们的意见)和一个更便携(Python)；Git是可脚本化的并且基于允许独立的重新实现的数据模型(参见例如JGIT，Java编写的Git)，而MyurialPython绑定用于编写扩展，并且主要基于API允许底层的改变。Ying存储库格式(revlog-revlog ng)…但这只是我的猜测。它们填补了稍有不同的壁龛。

    另外，没有选择是件好事吗？我们有kde和gnome和xfce(以及其他窗口管理器和桌面环境)；我们有emacs和vim(以及其他程序员的编辑器)；我们有基于RPM的(例如Fedora Core、Mandriva、Suse)和基于DEB的(Debian、Ubuntu)和基于TGZ的(Slackware)和基于源代码的(Gentoo)发行版；我们有kword、abiword和openoffice.org…我们有Git，Mercurial和Bazaar。

    相关讨论

    • 没有马上看到你的答案。+ 1。尽管我会谨慎对待"选择"的论点。尤其是当涉及到kde；)时(linuxathers.blogspot.com/2009/01/river-of-fail.html)
    • 我看不到你答案的最后一部分(只是"有点集中(我猜)")。如果你看不到最后两段，你所要做的就是做一个简单的编辑，以便恢复完整的内容。请参阅meta.stackexchange.com/questions/12988/&hellip；。
    • @VONC：谢谢你通知我。固定的。
    • Git文档遵循Unix的传统，它只解释每个命令的参数，但缺少详细的示例或图形，因此在阅读文档后可能无法理解任何内容。
    • @Linqueze：这就是"Git用户手册"(在与Git一起分发的HTML文档中)或"Pro Git"(免费电子书pro git.org)的含义；相当于hgbook。

    我使用并推荐Mercurial

    • 而不是颠覆，因为它支持分布式开发。我可以在几台机器上工作并在本地提交。对于Subversion，你不能这样做，至少不能像其他存储库那样没有翻筋斗。
    • 而不是Bazaar，因为Bazaar的Windows支持是…好。
    • 而不是Git，因为它a)学习和使用更简单b)Windows支持更好
    相关讨论

    • imho mercurial对单个存储库中的多个命名分支以及与多个存储库和标记交互的支持比git差。但这只是我的观点，对您来说，为单个(可见)分支使用单个存储库可能更简单。
    • 你能解释一下吗："而不是集市，因为集市的Windows支持是……好吧。"？我不明白你的意思。
    • 市场对Windows的支持有一些问题，至少在我上次尝试的时候。尤其是从Windows和Linux机器的混合提交时
    • 到底有什么问题？
    • 阅读此链接lists.ubuntu.com/archives/bazaar/2009q1/054082.html了解详细信息
    • @康拉德：给定的链接并没有真正显示Bazaar的问题，更多的是关于Windows工具的一般用法…(适当的编辑等)。此外，最新版本改进了Windows支持(使用EOL筛选器和类似功能)。仍然不完美(例如，在某些命令的文件名中使用Unicode字符)，但正在改进…
    • @康拉德，这实际上是我最初选择BZR的主要原因之一，因为它支持本地的Windows。当我第一次移动到DVC时，我想使用Git，但它没有本地的Windows支持。现在我已经在Ubuntu上了，这一点对我个人来说并不重要，但是BZR仍然拥有三个最好的UI之一，IMO，所以我一直坚持着。
    • 让我再检查一下BZR。2年在计算机时代是很长的一段时间

    根据我的经验，从问题的数量来看，这明显扭曲了与Git和Mercurial的对比。原因有两方面：

  • 看看hg update --help对git checkout -h和git --help checkout的对比。我用反复无常的眼光，发现了一些问题，没有用几眼的眼光回答。

  • 查看mercurial wiki-如果您需要帮助，您可能会在那里找到它，包括许多提示和技巧：http://mercurial-scm.org/wiki/tipsandtricks

    • 相关讨论

    • 我同意。同样，对于bzr help update或bzr update --help或bzr --help update或bzr -h update(注意bzr可以处理所有常见的语法和词汇)。替换你最喜欢的hg、git或svn vcs命令，你会发现bzr也可以帮助你。当hg和bzr离线回答你的问题时，不需要在stackoverflow上发布。

    [注：随着Subversion 1.7的发布，下面我的答案中的第一段已经过时，因为Subversion现在只在基本文件夹中创建一个".svn"文件夹，与其他文件夹类似。]

    与Subversion相比，这三个文件夹的一个优点是，它不会在项目的每个文件夹中创建一个与".svn"文件夹等效的文件夹。通常在基本文件夹中只有一个(".hg"、".bzr"或".git")。即使您使用的是集中式存储库模型，单凭这一点就可以很好地在SVN上使用它们中的一个。(除此之外：事实上，我经常使用SVK作为我的SVN客户机，而仅仅是为了这个特性而使用SVN存储库(不过，仅在Linux上，SVK在Windows上并不好)。

    当然，Subversion的一个优点是，如果只需要一个子文件夹，就不必签出整个项目。

    相关讨论

    • SVN 1.7不再具有每个文件夹。SVN
    • @卡文，谢谢。我修改了我的答案来反映这一点。

    Canonical(Ubuntu)跟踪软件包为自己使用的发行版，所以没有需要两个堆栈rely在线交易两项popularity计数问题。然而，有了为他人芒，这是唯一的Ubuntu用户跟踪和Canonical(Ubuntu)和recommends辨别bzr(样品偏压)。nonetheless…

    1
    2
    3
    4
    5
    6
                2011    2011    2011          
    Package     Aug 3   Sep 29  Dec 9   Change
    ------      ------  ------  ------  ------
    git-core    3647    3402    3236    -11%  
    bzr         4975    5286    6070    +22%  
    mercurial   3411    3387    3461     +1%

    的下降在投票的Git芯包让我认为我做什么什么样的错误的错误greped package name从Ubuntu popularity表。或者甚至是"投票""count冰相关的安装和没有实际使用的软件。

    这里的一些历史数据的东西。在过去的而不是在这个国家从Ubuntu的节目表，但它生长在一个冲刺的集市和mercurial在2011年开始。nonetheless bzrgit背后，是在2011年，但近年来国家对2011年的展，它通过在全gitinstances(在安装Ubuntu)。

    1
    2
    3
    4
    5
    6
            June    Aug     Dec     Growth  Oct   Growth
            2010    2011    2011            2013
    ----    -----   ----    ----    ------  ----  ------
    git      94k    159k    171k      80%   165k   -3.5%
    bzr      52k    121k    135k     160%   170k   26.0%
    hg       36k     68k     75k     110%    95k   26.7%

    discalaimer：bzr在线使用Ubuntu，直到2012年的时候，在团队工作gitexclusively使用。好的bzr剧目，与所有其他vcses，allowing你使用bzr洽，直观的命令行语法。我的两个git开关是社会而不是技术原因。

    相关讨论

    • 下载统计信息不是安装统计信息。他们指出有多少人尝试过它，而不是有多少人最终坚持了它。
    • @米基，说得对。下载网站访问图没有用(只是看起来很漂亮)。但是stats表和源数据链接用于安装而不是下载。如果你真的想知道使用计数(常规的活跃用户)，链接也有这个——见9/11的(popcon.ubuntu.com/by诳inst)上的栏，"卡住它"的比率是git=2%，bzr=4%，hg=5%。所以BZR几个月前就通过了Git，成为UbuntuLinux上使用最多的VCS，而Hg很快就会通过Git。
    • 这些数字显示了巨大的样本偏差。这些只是从UbuntuLinux下载的。Canonical控制Ubuntu和Bazaar；Canonical为其项目使用Bazaar，包括Ubuntu。这两者之间显然有很高的相关性。除此之外，Git在Linux上比在Windows上更受欢迎(我想Mercurial也是如此)。(我在这场战斗中没有狗。我在Linux上使用Git，但我需要在Windows上使用其他东西，无法决定Bazaar和Mercurial之间的关系。)
    • 同意样品偏差。除了Ubuntu之外，Git在Linux上的发行版似乎更受欢迎，我知道BZR是Canonical的狗。但是我能找到的唯一硬用法统计数据(不仅仅是安装)是针对Ubuntu的。我假设列(而不是列)中的Ubuntu"active users"stat是准确的，因为canonical/Ubuntu基于这些统计信息以开发和支持为目标。
    • @然而，SO问题的统计也受到巨大样本偏差的影响。希望这两个偏差是独立的，这样读者就可以将这些结果结合起来，得到比问题中给出的数字和一些答案稍微少一些的偏差统计数据。

    自从GitHub上Git的社交编码起源以来，Git似乎吸引了很多追随者。

    相关讨论

    • 没有回答问题，但我同意。GitHub真是太棒了；尽管我相信BitBucket和其他人已经介入填补了其他DVCSS的空白。
    • 是的，设置BitBucket比GitHub更容易。这非常简单，因为如果您不介意ssh的话，也可以使用http。

    Git有这么多用户的原因是Linux内核使用它，所以如果您想进行Linux开发，就使用Git。

    因为有这么多人参与了Git，我建议使用Git，这仅仅是因为它拥有更大的用户群。事实上，上面显示的数字是这一点的明显标志。

    至于难度，所有版本控制都很困难，特别是分布式版本控制。SVN和CVS乍看起来并不容易(至少对我来说)。这只是习惯于版本控制系统的必要学习曲线的一部分。

    编辑：既然你添加了一个Subversion引用，我想我会解决它。我认为大多数人会使用SVN，因为它有各种各样漂亮的GUI接口。一般来说，人们不喜欢使用命令行，包括一些开发人员。Git在Windows上通常也不能很好地工作(或者至少不能无缝地工作)。由于许多人都在Windows上，这会扼杀潜在用户的数量。

    此外，我认为SVN的概念更容易理解，因为SVN使用中央存储库而不是分布式系统。更容易理解的是，"这里是代码的大山，请在这里添加您的代码，"而"这里是一些代码，我的可能不同于他的，他的和她的，但如果您愿意，您可以添加一些东西。"

    在我看来，SVN有一个更好的文档系统。Git的文档针对的是更高层次的知识(程序的知识，而不是程序员的智能)，因此在您使用系统之后是有意义的，但是当第一次启动时，它看起来就像一堆Gobbeldy Gook。

    总的来说，我认为SVN现在和将来都会更加流行，因为它的一般操作概念更容易理解，工具也更容易使用，而且它在Windows上有极好的支持。

    不过，让我以最后两分钱结束，并说我更喜欢Git，因为我认为它比我使用的任何其他系统都强大得多。一旦你开始更好地理解程序，爬上学习曲线肯定会有回报。

    相关讨论

    • 您只需填写git和svn。你试过汞和巴扎吗？"比我用过的任何一个都强大"并不能很好地回答这个问题，如果你没有说明你用的是哪一个。

    检查下面的链接)在两个主题：

    http：/ / / / 160 www.debian-administration.org民调

    我不normally邮件但…………………

    在这里我想出去，和其他一些bzr忘记bzr招领有极极弱一点。"坚持男女大档案信息在整个文件加载到存储器中。这个大的二进制文件创建的问题。

    Git是一批更好，在那方面。AS的难度。在Windows中使用Git Bash从Git。大鸭厂为止，在不到一周(，包括实际的工作和与其他experimenting VCS)

    埃里克·辛克的一篇关于他们的有趣的博客文章。

    相关讨论

    • 另请参阅此博客的评论，以及有关Eric Sink博客文章的git邮件列表中的以下线程：thread.gmane.org/gmane.comp.version-control.git/117659
    • 颠覆是摩根·弗里曼。