svn -为什么Git比Subversion好?

Translate

我一直在用颠覆使用几年后SourceSafe,我只是喜欢Subversion。结合乌龟SVN,我真的无法想象它会变得更好。

但是,越来越多的开发人员声称Subversion存在问题,我们应该转向新型的分布式版本控制系统,例如吉特.

Git在Subversion上有何改进?

This question and all comments follow the "Attribution Required."

所有的回答

Translate

Git并不比Subversion好。但是也不差。这是不同的。

关键区别在于它是分散的。假设您是旅途中的开发人员,您在笔记本电脑上进行开发,并且想要进行源代码控制,因此可以返回3个小时。

使用Subversion,您会遇到一个问题:SVN信息库可能位于您无法访问的位置(在公司中,并且您目前没有互联网),因此无法提交。如果要复制代码,则必须逐字复制/粘贴。

使用Git,您就不会遇到这个问题。您的本地副本是一个存储库,您可以对其进行提交并获得源代码管理的所有好处。重新获得与主存储库的连接时,可以对其进行提交。

起初看起来不错,但请记住此方法会增加复杂性。

Git似乎是“新的,闪亮的,酷的”东西。这绝不是一件坏事(毕竟,Linus为Linux Kernel开发编写了它是有原因的),但是我感到很多人跳入“分布式源代码控制”火车只是因为它是新的,并且是由Linus Torvalds编写的,实际上没有知道为什么/如果更好。

Subversion有问题,但是Git,Mercurial,CVS,TFS或其他问题也有问题。

编辑:因此,此答案已有一年的历史了,仍然产生了很多反对意见,所以我想我将添加更多解释。自撰写本文以来的最后一年,Git获得了很多动力和支持,尤其是自GitHub之类的网站真正腾飞以来。如今,我同时使用Git和Subversion,并希望分享一些个人见解。

首先,在分散工作时,Git最初可能确实会造成混淆。什么是遥控器?以及如何正确设置初始存储库?一开始会出现两个问题,特别是与SVN的简单“ svnadmin create”相比,Git的“ git init”可以采用--bare和--shared参数,这似乎是设置集中式管理的“正确”方法资料库。这是有原因的,但是会增加复杂性。 “ checkout”命令的文档对于转换的人非常混乱-“正确”的方式似乎是“ git clone”,而“ git checkout”似乎是切换分支。

当您分散时,Git确实会发光。我在家中有一台服务器,在旅途中有一台笔记本电脑,而SVN在这里根本无法正常工作。使用SVN,如果我未连接到存储库,则无法获得本地源代码控制(是的,我知道SVK或复制存储库的方式)。无论如何,使用Git都是默认模式。但是,这是一个额外的命令(git commit在本地提交,而git push origin master将master分支推送到名为“ origin”的远程)。

如上所述:Git增加了复杂性。创建存储库的两种模式,即检出与克隆,提交与推送......您必须知道哪些命令在本地工作以及哪些命令与“服务器”一起工作(我假设大多数人仍然喜欢中央的“主存储库” )。

而且,该工具仍然不足,至少在Windows上是如此。是的,有一个Visual Studio插件,但是我仍然将git bash与msysgit一起使用。

SVN的优点是学习起来非常简单:存在您的存储库,所有对它的更改,如果您知道如何创建,提交和签出,并且准备就绪,可以稍后进行分支,更新等操作上。

如果某些开发人员不总是连接到主存储库,则Git的优势是更适合。而且,它比SVN快得多。从我听到的信息来看,分支和合并支持要好得多(这是可以预料的,因为这是编写它的核心原因)。

这也解释了为什么它在Internet上获得如此多的关注,因为Git非常适合于开放源代码项目:只需进行分叉,将更改提交到自己的Fork中,然后要求原始项目维护者进行更改即可。使用Git,这是可行的。真的,在Github上尝试一下,这很神奇。

我还看到了Git-SVN桥:中央存储库是Subversion存储库,但是开发人员在本地使用Git,然后桥将其更改推送到SVN。

但是即使有这么长的时间,我仍然坚持我的核心信息:Git并不好坏,只是有所不同。如果您需要“离线源代码控制”,并且愿意花一些额外的时间来学习它,那就太好了。但是,如果您有严格集中的Source Control,并且/或者由于您的同事不感兴趣而一开始就在努力引入Source Control,那么SVN的简单性和出色的工具(至少在Windows上是如此)非常出色。

来源
Translate

使用Git,您几乎可以脱机执行任何操作,因为每个人都有自己的存储库。

制作分支和在分支之间合并确实很容易。

即使您没有项目的提交权限,您仍然可以在线拥有自己的存储库,并为补丁发布“推送请求”。每个喜欢您的补丁程序的人都可以将其加入他们的项目中,包括官方维护人员。

派生一个项目,对其进行修改,并且仍然保持合并来自HEAD分支的错误修正,这是微不足道的。

Git为Linux内核开发人员服务。这意味着它确实非常快(必须如此),并且可以扩展到成千上万的贡献者。 Git还使用更少的空间(Mozilla存储库的空间最多减少30倍)。

Git非常灵活,非常TIMTOWTDI(有多种方法可以做到)。您可以使用所需的任何工作流程,Git将支持它。

最后,有的GitHub,一个托管Git存储库的好网站。

Git的缺点:

  • 这很难学习,因为Git具有更多概念和更多命令。
  • 修订版没有像Subversion中那样的版本号
  • 许多Git命令是模糊的,错误消息对用户非常不友好
  • 它缺少良好的GUI(例如乌龟SVN)
来源
Translate

其他答案也很好地解释了Git的核心功能(很棒)。但是也有很多Git表现得更好并有助于保持我的生活更加理智的方式。以下是一些小事情:

  1. Git有一个“干净”的命令。考虑到SVN多长时间将额外的文件转储到磁盘上,SVN迫切需要此命令。
  2. Git具有“ bisect”命令。这真好。
  3. SVN在每个文件夹中创建.svn目录(Git仅创建.git目录)。您编写的每个脚本以及所做的每个grep都需要编写以忽略这些.svn目录。您还需要一个完整的命令(“ svn export”),以获取文件的完整副本。
  4. 在SVN中,每个文件和文件夹都可以来自不同的修订版或分支。首先,拥有这种自由听起来不错。但这实际上意味着,有一百种不同的方法可以完全搞定本地结帐。 (例如,如果“ svn switch”中途失败,或者您输入的命令错误)。最糟糕的部分是:如果遇到某些文件来自一个地方,而另一些文件来自另一个地方的情况,则“ svn状态”将告诉您一切正常。您需要在每个文件/目录上执行“ svn信息”,以发现异常情况。如果“ git status”告诉您事情正常,那么您可以相信事情确实正常。
  5. 每当您移动或删除某些内容时,您都必须告诉SVN。 Git会弄清楚的。
  6. 在Git中,忽略语义更容易。如果您忽略某个模式(例如* .pyc),它将被忽略所有子目录。 (但是,如果您真的只想忽略一个目录,则可以)。使用SVN,似乎没有简单的方法可以忽略所有子目录中的模式。
  7. 另一个涉及忽略文件的项目。 Git使得“私有”忽略设置成为可能(使用文件.git / info / exclude),这不会影响其他任何人。
来源
Translate

"为什么Git比X更好概述了Git与其他SCM的优缺点。

简要地:

  • Git轨道内容而不是文件
  • 分支是轻量级的和合并是简单,我的意思是真的很容易.
  • 它是分布式的,基本上每个存储库都是一个分支。我认为,与Subversion相比,并行和协同开发要容易得多。这也使得离线发展成为可能。
  • 不强加任何工作流程,如上所示以上链接的网站,Git有许多工作流程。 Subversion样式的工作流很容易被模仿。
  • Git仓库很多文件较小比Subversion储存库。只有一个“ .git”目录,而不是数十个“ .svn”存储库(请注意Subversion 1.7及更高版本)现在使用一个目录像Git。)
  • 分期区域很棒,它使您可以看到将要提交的更改,提交部分更改以及进行其他各种操作。
  • 藏匿当您进行“混乱”开发时,或者只是想在仍在其他地方(在另一个分支上)工作时修复错误时,它是非常宝贵的。
  • 您可以改写历史,这对于准备补丁集和修复错误非常有用(之前您发布提交)
  • ……还有一个很多更多。

有一些缺点:

  • 目前还没有很多好的GUI。它是新的,Subversion已经存在了很长时间,所以这很自然,因为有一些接口正在开发中。一些好的包括龟龟Mac版GitHub.
  • 目前无法对存储库进行部分检出/克隆(我读到它正在开发中)。但是,有子模块支持。 Git 1.7+支持稀疏签出.
  • 即使我(大约一年前)没有发现这种情况,可能很难学习。 Git最近改进了其界面,并且非常用户友好。

在最简单的用法中,Subversion和Git几乎相同。之间没有太大区别:

svn checkout svn://foo.com/bar bar
cd bar
# edit
svn commit -m "foo"

git clone [email protected]:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push

Git真正令人眼前一亮的是分支机构并与其他人一起工作。

来源
Parker Lee
Translate

Google Tech Talk:git上的Linus Torvalds

http://www.youtube.com/watch?v=4XpnKHJAok8

Git Wiki的比较页面

http://git.or.cz/gitwiki/GitSvnComparsion

来源
Translate

好吧,它是分布式的。基准测试表明它的速度要快得多(考虑到它的分布式特性,差异和日志之类的操作都是本地的,因此在这种情况下当然要快得多),并且工作文件夹更小(这仍然让我震惊)。

在从事Subversion或任何其他客户端/服务器版本控制系统的工作时,您基本上可以通过以下方式在计算机上创建工作副本:签出修订。这代表了存储库外观的快照。您通过更新来更新工作副本,并通过提交来更新存储库。

使用分布式版本控制,您没有快照,而只有整个代码库。想与3个月大的版本进行比较吗?没问题,使用3个月的旧版本仍在您的计算机上。这不仅意味着运行速度更快,而且即使您与中央服务器断开连接,您仍然可以执行许多惯用的操作。换句话说,您不仅拥有给定修订的快照,而且还拥有整个代码库。

您可能会认为Git会占用硬盘驱动器上的一堆空间,但是从我所看到的一些基准测试来看,它实际上花费的空间更少。不要问我如何。我的意思是,它是由Linus构建的,我猜他对文件系统了解一两件事。

来源
Translate

我喜欢DVCS的要点是:

  1. 您可以犯坏的事情。没关系,因为在您发布之前,其他人不会看到它们。发布时间与提交时间不同。
  2. 因此,您可以更频繁地进行提交。
  3. 您可以合并完整的功能。此功能将有其自己的分支。该分支的所有提交都将与此功能相关。您可以使用CVCS来实现,但是默认使用DVCS来实现。
  4. 您可以搜索历史记录(在功能更改时查找)
  5. 如果有人搞砸了主存储库,则可以撤消拉动,而无需修复错误。只需清除合并即可。
  6. 当您需要任何目录中的源代码管理时,请执行:git init。您可以提交,撤消更改等。
  7. 快速(即使在Windows上)

进行相对大型项目的主要原因是第3点改善了沟通能力。其他都是不错的奖励。

来源
Christopher Lee
Translate

有趣的是:我在Subversion Repos中托管项目,但是通过Git Clone命令访问它们。

请阅读使用Git在Google Code项目上进行开发

尽管Google Code的母语是Subversion,但是您可以在开发过程中轻松使用Git。搜索“ git svn”表明这种做法很普遍,我们也鼓励您尝试一下。

在Svn存储库上使用Git给我带来了好处:

  1. 我能工作分散式在几台机器上,从它们之间提交和拉取
  2. 我有一个中央 backup/publicsvn存储库供其他人签出
  3. 他们可以自由使用Git
来源
Si.
Translate

此处的所有答案均符合预期,以程序员为中心,但是,如果您的公司在源代码之外使用修订控制,会发生什么情况?有很多不是源代码的文档可以从版本控制中受益,它们应该靠近代码,而不是放在另一个CMS中。大多数程序员并不是孤立地工作-我们作为团队的一员为公司工作。

考虑到这一点,请比较Subversion和git在客户端工具和培训中的易用性。我看不到一种情况任何分布式修订控制系统将更易于使用或向非程序员解释。我希望证明自己是错误的,因为这样我就可以评估git,并且实际上希望它可以被那些需要版本控制且不是程序员的人所接受。

即使这样,如果管理层问到为什么我们应该从集中式修订控制系统转移到分布式修订控制系统,我也很难给出一个诚实的答案,因为我们不需要它。

免责声明:我很早就对Subversion感兴趣(大约在v0.29左右),因此我有偏见,但是自那时以来我工作的公司都从我的热情中受益,因为我一直鼓励和支持Subversion的使用。我怀疑大多数软件公司都是这样的。如此众多的程序员加入git潮流,我想知道有多少公司会错过在源代码之外使用版本控制的好处吗?即使您为不同的团队使用单独的系统,您也会错过一些好处,例如(统一的)问题跟踪集成,同时增加了维护,硬件和培训要求。

来源
Translate

Subversion仍然是一种使用更为广泛的版本控制系统,这意味着它具有更好的工具支持。您几乎可以找到成熟的SVN插件集成开发环境,并且提供了不错的资源管理器扩展(例如TurtoiseSVN)。除此之外,我必须同意麦可:Git并不比Subversion更好或更糟,它有所不同。

来源
Prima Lee
Translate

让SubVersion感到困扰的一件事是,它在项目的每个目录中都放置了自己的文件夹,而git仅在根目录中放置了一个文件夹。不是没什么大不了的,但类似的小事加起来。

当然,SubVersion具有Tortoise,(通常)非常好。

来源
Adair Lee
Translate

David Richards WANdisco关于Subversion / GIT的博客

GIT的出现带来了许多DVCS原教旨主义者,即“吉特隆人”,他们认为除GIT之外的任何事物都是垃圾。 Gitterons似乎认为软件工程发生在自己的孤岛上,并且常常忘记大多数组织并没有专门雇用高级软件工程师。没关系,但这不是市场上其他人的想法,我很高兴证明这一点:GIT在最近的市场中所占份额不到3%,而Subversion的用户数量在500万左右,其中一半左右整体市场。

我们看到的问题是Gitterons在Subversion射击(便宜)。诸如“颠覆是如此的[缓慢//脚/限制性/不好闻/以一种有趣的方式看着我]这样的推文,现在我有了GIT,[我一生中的所有工作/我的妻子怀孕了/我之后有了女朋友30年的尝试/我在二十一点桌上赢得了六次胜利]。您得到图片。

来源
Translate

Git还使分支和合并变得非常容易。 Subversion 1.5刚刚添加了合并跟踪,但是Git仍然更好。使用Git分支非常快速且便宜。这使得为每个新功能创建分支更加可行。与Subversion相比,Oh和Git存储库在存储空间方面非常有效。

来源
Hazel Lee
Translate

一切都与执行某件事所需的易用性/步骤有关。

如果我要在PC /笔记本电脑上开发单个项目,则git会更好,因为它更容易设置和使用。您不需要服务器,也不需要在合并时继续输入存储库URL。

如果只有2个人,我想说git也更容易,因为您可以互相推拉。

但是,一旦您超出了这个范围,我就会进行颠覆,因为那时候您需要设置一个“专用”服务器或位置。

您可以使用git和SVN一样好地执行此操作,但是由于需要执行其他步骤来与中央服务器同步,所以git的好处远远超过了git。在SVN中,您只需提交即可。在git中,您必须先进行git commit,然后进行git push。仅仅因为您最终做了太多事情,其他步骤就变得很烦人。

SVN还具有更好的GUI工具的好处,但是git生态系统似乎正在迅速赶上,因此从长远来看,我不必担心。

来源
Abigail Lee
Translate

简易Git有一个不错的页面,比较了Git和SVN与SVN相比,它可以让您了解Git可以做什么(或做起来更容易)。 (从技术上讲,这是基于Easy Git的,它是Git之上的轻量级包装。)

来源
Clement Lee
Translate

一般来说,Git和DVCS非常适合开发人员彼此独立进行大量编码的开发人员,因为每个人都有自己的分支。但是,如果您需要其他人进行更改,则她必须提交其本地存储库,然后她必须将该更改集推送给您,或者您必须从她那里撤消它。

我自己的推理也使我认为,如果您进行集中发布等操作,DVCS会使质量检查和发布管理更加困难。必须由其他人负责从其他所有人的存储库中进行该推/拉操作,解决在最初的提交时间之前已经解决的所有冲突,然后进行构建,然后让所有其他开发人员重新同步其存储库。

当然,所有这些都可以通过人工流程解决。 DVCS只是打破了集中版本控制所修复的问题,以便提供一些新的便利。

来源
Translate

我喜欢Git,因为它实际上可以帮助中大型团队的开发人员之间进行交流。作为一个分布式版本控制系统,通过其推/拉系统,它可以帮助开发人员创建源代码生态系统,从而有助于管理在单个项目上工作的大量开发人员。

例如,说您信任5个开发人员,并且仅从其存储库中提取代码。每个开发人员都有他们自己的信任网络,从那里可以提取代码。因此,开发基于开发人员的信任结构,其中代码责任在开发社区之间共享。

当然,这里的其他答案中也提到了其他好处。

来源
Translate

这些都暗示了一些答案,但我想明确指出两点:

1)进行选择性提交的能力(例如,git add --patch)。如果您的工作目录包含不属于同一逻辑更改的多个更改,则Git使得进行仅包含部分更改的提交非常容易。使用Subversion很难。

2)在不公开更改的情况下进行提交的能力。在Subversion中,任何提交都会立即公开,因此不可撤消。这极大地限制了开发人员“提早提交,经常提交”的能力。

Git不仅仅是一个VCS;它也是开发补丁的工具。 Subversion仅仅是一个VCS。

来源
Translate

我认为Subversion很好..直到您开始合并..或做任何复杂的事情..或做Subversion认为很复杂的事情(例如执行查询以找出哪个分支与特定文件弄乱了,在哪里进行更改)其实来自,检测复制和粘贴等)...

我不同意胜出的答案,说主要好处GIT的工作是脱机工作-肯定有用,但是对于我的用例来说,它更像是一个额外的东西。 SVK也可以脱机工作,但毫无疑问,我可以选择哪个时间来投入我的学习时间。

只是,它功能强大且快速,并且在习惯了这些概念之后非常有用(在某种意义上是:用户友好)。

有关合并故事的更多详细信息,请参见:使用git-svn(或类似的)*只是*来帮助svn合并?

来源
Sigrid Lee
Translate

由于它不需要与中央服务器持续通信的事实,几乎每个命令都可以在不到一秒钟的时间内运行(显然git push / pull / fetch速度较慢,只是因为它们必须初始化SSH连接)。分支要容易得多(一个简单的命令即可分支,一个简单的命令即可合并)

来源
Translate

我绝对喜欢能够在Git中管理我的源代码的本地分支,而又不会浪费中央存储库的资源。在许多情况下,我都会从Subversion服务器中签出代码,然后运行本地Git存储库以实现此目的。初始化Git存储库不会污染到处都是一堆烦人的.svn文件夹,这也很棒。

就Windows工具的支持而言,TortoiseGit能很好地处理基础知识,但是除非我想查看日志,否则我还是更喜欢命令行。我非常喜欢Tortoise {Git | SVN}在读取提交日志时的帮助方式。

来源
Rosemary Lee
Translate

这是一个错误的问题。专注于git的疣,就至少在某些用例中,Subversion为何表面上看起来更好更好,形成论点太容易了。 git最初被设计为低级版本控制构造集,并且具有面向Linux开发人员的巴洛克式界面,这一事实使圣战更容易获得吸引力和合法性。 Git的拥护者以数百万个工作流程的优势振奋人心,这使svn家伙宣称没有必要。很快,整个辩论被归结为集中式与分布式,这符合企业svn工具社区的利益。这些公司通常发布有关颠覆在企业中的优势的最有说服力的文章,取决于git的不安全感和svn为企业的长期成功所做出的企业准备。

但这是问题所在:Subversion是架构上的死胡同.

尽管svn的使用时间是svn的两倍以上,但您甚至可以轻松地使用git并构建集中式的subversion替代品,甚至无法在git中达到甚至与svn一样的基本合并跟踪。这样做的一个基本原因是使分支与目录相同的设计决策。我不知道为什么他们本来会这样,这肯定会使部分结帐非常简单。不幸的是,这也使得无法正确跟踪历史记录。现在显然您应该使用颠覆存储库布局约定来将分支与常规目录分开,并且svn使用一些启发式方法使事情在日常使用情况下正常工作。但是,所有这些都只是在记录一个非常糟糕且有限的低级设计决策。能够执行版本库差异(而不是目录差异)是版本控制系统的基本和关键功能,它极大地简化了内部结构,从而有可能在其之上构建更智能,更有用的功能。您可以看到扩展颠覆所付出的努力,但是从诸如合并解析之类的基本操作来看,它与当前的现代VCS相比有多远。

现在,这是我对那些仍然相信Subversion在可预见的未来足够好的人的衷心和不可知的建议:

Subversion永远不会赶上从RCS和CVS的错误中吸取教训的新型VCS。除非他们从头开始重新构建存储库模型,否则这在技术上是不可能的,但是那真的不是svn吗?无论您认为自己没有现代VCS的功能有多少,您的无知都不会使您免受Subversion的陷阱的困扰,其中许多情况是其他系统无法或无法轻松解决的。

像svn一样,解决方案的技术劣势如此明显是极为罕见的,当然我永远不会对win-vs-linux或emacs-vs-vi提出这样的看法,但是在这种情况下,它是如此明确,源代码控制是开发人员手中的如此基本工具,我认为必须明确指出。不管出于组织原因而使用svn的要求,我恳求所有svn用户不要让他们的逻辑思维错误地认为,更现代的VCS仅对大型开源项目有用。不管开发工作的性质如何,如果您是一名程序员,那么如果您学会了如何使用设计更好的VCS(无论是Git,Mercurial,Darcs还是其他许多类型的VCS),您将成为一名更有效的程序员。

来源
Translate

Subversion非常易于使用。在过去的几年中,我从未发现任何问题或某些功能无法正常工作。另外,还有许多出色的GUI工具,并且对SVN集成的支持很大。

使用Git,您可以获得更灵活的VCS。您可以像在远程仓库中使用SVN一样使用它,在该仓库中提交所有更改。但是您也可以在离线状态下使用它,并且仅将更改不时推送到远程存储库。但是Git更复杂,学习曲线更陡峭。我第一次发现自己犯了错误的分支,间接创建分支或收到错误消息,但其中包含有关错误的信息以及我必须在Google进行搜索以获取更好信息的信息不多。一些简单的事情(例如标记的替换($ Id $))不起作用,但是GIT具有非常灵活的筛选和挂钩机制来合并自己的脚本,因此您可以获得所需的所有东西,但还需要更多的时间和文档阅读时间;)

如果您大多数情况下是使用本地存储库进行脱机工作,则如果本地计算机上丢失了某些内容,则将没有备份。使用SVN时,您主要是在使用远程存储库,这也是您在另一台服务器上备份的同时。Git可以以相同的方式工作,但这不是Linus拥有SVN2之类的主要目标。它是为Linux内核开发人员和分布式版本控制系统的需求而设计的。

Git比SVN好吗?只需一些版本历史记录和备份机制的开发人员,使用SVN可以轻松自如。经常与分支机构合作,同时测试更多版本或大部分离线工作的开发人员可以从Git的功能中受益。有一些非常有用的功能,例如SVN找不到的隐藏功能,可以使生活更轻松。但另一方面,并非所有人都需要所有功能。因此,我看不到SVN的死机。

Git需要一些更好的文档,并且错误报告必须更有帮助。而且,现有有用的GUI很少。这次,我只找到1个Linux的GUI,它支持大多数Git功能(git-cola)。 Eclipse集成正在运行,但尚未正式发布,并且没有官方更新站点(仅某些具有定期从主干构建的外部更新站点http://www.jgit.org/updates)因此,目前使用Git的首选方法是命令行。

来源
Translate

埃里克·辛克来自SourceGear的文章撰写了有关分布式版本控制系统和非分布式版本控制系统之间差异的系列文章。他比较了大多数流行的版本控制系统的优缺点。非常有趣的阅读。
可以在他的博客上找到文章,www.ericsink.com:

来源
Godfery Lee
Translate

对于寻求良好Git GUI的人,Syntevo SmartGit可能是一个很好的解决方案。我认为,它的专有但免费用于非商业用途,可以在Windows / Mac / Linux上运行,甚至可以使用某种git-svn桥来支持SVN。

来源
Simona Lee
Translate

http://subversion.wandisco.com/component/content/article/1/40.html

我认为可以肯定地说,在开发人员中,SVNVs。 Git的争论已经持续了一段时间,每个人都对哪个更好有自己的看法。在我们于2010年及以后举办的有关Subversion的网络研讨会中,甚至提出了这些问题。

我们的开源总监兼Subversion公司总裁Hyrum Wright谈到了Subversion与Git以及其他分布式版本控制系统(DVCS)之间的区别。

他还谈到了Subversion即将发生的变化,例如下一代工作副本(WC-NG),他认为这将导致许多Git用户转换回Subversion。

观看他的视频,并通过评论此博客或在我们的论坛中发布让我们知道您的想法。注册很简单,只需要一点时间!

来源
Charlotte Lee
Translate

Windows中的Git现在已得到很好的支持。

签出GitExtensions =http://code.google.com/p/gitextensions/

和手册,以获得更好的Windows Git体验。

来源
Translate

我最近一直居住在Git土地上,我喜欢将其用于个人项目,但是鉴于工作人员对需求的看法发生了变化,如果没有紧迫的好处,我还无法将工作项目从Subversion切换到它。此外,我们内部开展的最大项目非常依赖svn:外部从我到目前为止所见,这在Git中无法很好地,无缝地工作。

来源
Yar
Translate

首先,并发版本控制似乎是一个容易解决的问题。一点也不。无论如何...

SVN非常不直观。 Git更糟。 [讽刺的推测]这可能是因为像并发版本控制之类的难题一样,开发人员对制作一个好的UI没有太大兴趣。 [/讽刺推测]

SVN支持者认为他们不需要分布式版本控制系统。我也这么认为。但是,既然我们只使用Git,我就是一个信徒。现在,版本控制对我和团队/项目都有效,而不仅仅是为项目工作。当我需要分支时,我分支。有时,这是一个分支,在服务器上具有相应的分支,有时则没有。更不用说我必须继续研究的所有其他优点(部分由于现代版本控制系统的UI荒唐而荒唐的缺乏)。

来源
Omar Lee
Translate

为什么我认为Subversion比Git更好(至少对于我从事的项目而言),主要是因为它的可用性和更简单的工作流程:

http://www.databasesandlife.com/why-subversion-is-better-than-git/

来源