非要说的话就是:一个 svn 仓库的任何一个子目录,均可以被单独 checkout 成为一个仓库或者说一个项目。
而 git 要想实现类似的子仓库机制是需要人为干预的,而且也相对麻烦。我有时甚至觉得,android 源代码之所以使用 repo 给 git 包了一层,是不是就为了解决 git 本身并不方便处理子目录的问题。
比方说我们一个产品用一个 svn 库,其中有各方面的项目,有ios的linux的android的windows的项目。某些项目是无法签出到特定平台的,比如Windows平台有大小写限制(仅大小写不同的文件不能出现在同一个目录内),那么这样的目录无法签出到Windows。而这种时候,单独签出Windows相关子目录就可以实现不影响iOS或Linux目录文件结构。
与之同时带来的好处就是可以一个整产品只建一个仓库,而没必要为产品中的每个项目单独建一个仓库。
如果拿 Android Studio 为例子来说的话,svn你建产品级的仓库,每个项目都可以单独打开单独操作,因为每个项目都同时是以自己项目根目录的独立仓库。但 git 如果你的仓库根目录不是在项目那一级,就没法很好的集成进 IDE 的操作。于是 git 就只适合每个项目独立建仓库。
我不知道为什么大家总是会说svn只适合小型团队,而大型团队适合git?
但我的经验恰恰是相反的。
git在大型团队里有什么问题呢?
首先是性能太差了,动辄几个G的库,每次pull都是全量下来,一下就干等几分钟,运气不好十几分钟。如果觉得等等不是问题的话,那考虑下有异地分部的大型公司,哪怕拉专线,几个人异地pull几个G下来,也非常容易把带宽吃干净。
然后就是权限问题。越是大型团队,内部子团队的分工就越清晰明确,所涉及的代码和权限也就非常清楚。把一整个库全都用同一个权限,基本上就等于不设权限。要按团队分权限,那么只能是分不同的库。越是大团队,各级细分团队就越多,那么就只能不停的细分库,最后就是一团乱麻。所以不管分不分库,最终结果就是要么是一团超级大的乱麻,要么是一大堆小乱麻,看兴趣挑一种。
再接着就是健壮性问题,虽然说起来,分布式的git不容易搞挂。但是要是有几个二百五使乱搞的话,搞丢部分信息(如日志、分支等),还是不难的。svn也许大问题的健壮性不咋地(毕竟集中在服务器),但是小问题的健壮性还是ok的。
最后就是如果用svn,团队里只需要一个svn专家,和一台强大的svn服务器。而用git的话,需要每个人都是git的高手——最起码要每个人都能分清楚什么时候用merge,什么时候用rebase,才能比较顺利的玩好git。
一个非常重要的特性:
1、SVN客户端几乎所有的操作和指令,都不会导致你的本地修改丢失。也就是说你只用SVN指令的时候,本地修改无论如何也不会丢失(除非明确的手动revert,)。
2、SVN客户端所有的操作和指令,都不会导致已经提交的版本消失。换言之只要你提交了,不管你怎么作死,版本都不可能丢失。
所以对于初学者来说,SVN可以随便你瞎JB折腾,不至于丢东西。但是Git你必须先把说明书看完再动手……
本站所有内容均为互联网搜索引擎提供的公开搜索信息,本站不存储任何数据与内容,任何内容与数据均与本站无关,如有需要请联系相关搜索引擎包括但不限于百度,google,bing,sogou 等
© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有