美高梅官方网站66159

CVS版本调控系统是一种GNU软件包,即使很五连串曾经起来从Subversion与CVS上扩充搬迁

作者:美高梅官方网站66159    来源:未知    发布时间:2020-05-02 09:38    浏览量:

目前,Eclipse上使用Git的项目数量已经超过了使用SVN的仓库数,这使得Git独树一帜,成为Eclipse项目最为流行的版本控制系统。虽然Git自从Helios发布后就已经出现了,但迁移到Git仅仅从去年夏天Eclipse Indigo发布后才开始。

对于软件开发人员来说,版本控制系统他们再熟悉不过了,所谓版本控制系统就是软件项目开发过程中用于储存开发人员所写代码所有修订版本的软件。它的主要目的是实现开发团队并行开发、提高开发效率,对软件开发进程中文件或目录的发展过程提供有效的追踪手段,保证在需要时可回到旧的版本,避免文件的丢失、修改的丢失和相互覆盖,从而减轻开发人员的负担,节省时间,同时降低人为错误。而目前常见的版本控制系统分为集中式版本控制系统和分布式版本控制系统两种。

虽然很多项目已经开始从Subversion与CVS上进行迁移,但还有不少项目依然在使用CVS或Subversion仓库。这些项目很可能会在Indigo SR2发布后被清理掉,到期时间为今年2月份。值得强调的是,CVS将会在今年底变为只读状态,但在今年夏天Eclipse Juno发布时将不会再有CVS仓库了。

SVN和Git

更有趣的是Eclipse上Git项目的增长并非来自于对CVS仓库的替换,而是来自于对SVN仓库的替换。目前,CVS占据了Eclipse上不到40%的仓库,其中很多项目的年代都很久远,他们一直位于Eclipse上,比如核心平台与IDE组件等。这些项目都在等待Indigo SR2发布后就完全迁移至Git上。SVN仓库的比例下降得却很快,目前只有不到20%的项目还在使用Subversion。这在一定程度上是因为我们可以更轻松地将SVN项目的导入自动转换到Git上而无需行政上的文件做保证;但还有一部分原因是出于历史原因,一些项目无法从CVS上迁移出来,而新项目则更加敏捷。

在集中式版本控制系统中,目前比较常用的是SVN,而说起SVN就不能不谈CVS,CVS是一个C/S系统,主要在开源软件管理中使用。多个开发人员通过一个中心版本控制系统来记录文件版本,从而达到保证文件同步的目的。CVS版本控制系统是一种GNU软件包,主要用于在多人开发环境下的源码的维护。但是由于CVS编码存在一些问题,大多数软件开发公司都使用SVN替代了CVS。SVN是Subversion的简称,是一个开放源代码的版本控制系统,相较于RCS、CVS,它采用了分支管理系统,它的设计目标就是取代CVS。互联网上很多版本控制服务已从CVS迁移到Subversion。说得简单一点SVN就是用于多个人共同开发同一个项目,共用资源的目的。

与此同时,在Apache上,官方的Apache Subversion仓库上已经有个只读的git项目镜像。然而,当CouchDB想要迁移到git上时,Apache却认为这么做是不行的。有些人觉得这是因为Apache Subversion项目在作祟;但事实上,Subversion一直以来都是Apache首选的仓库,甚至在Subversion项目从collabnet迁移到Apache之前就是这样的了。

而在分布式版本控制系统中,Git逐渐占据了上风,目前,国外最大的社交编程及代码托管网站Github,Bitbucket,Gitlab,国内的码云、Coding、华为软件开发云(DevCloud)中的配置管理等代码托管平台均支持Git。Git是一款免费、开源的分布式版本控制系统,可以有效、高速的处理从很小到非常大的项目版本管理。Git是Linus Torvalds为了帮助管理Linux内核开发而开发的一个开放源码的版本控制软件。Torvalds 开始着手开发 Git 是为了作为一种过渡方案来替代 BitKeeper,后者之前一直是Linux内核开发人员在全球使用的主要源代码工具。开放源码社区中的有些人觉得BitKeeper 的许可证并不适合开放源码社区的工作,因此Torvalds决定着手研究许可证更为灵活的版本控制系统。尽管最初Git的开发是为了辅助Linux内核开发的过程,但是我们已经发现在很多其他自由软件项目中也使用了Git。

更新:有人已经提议允许Apache的孵化项目使用Git,这样就可以提前准备好一些Git资源以便Git仓库的管理。如果这么做是可行的,那么这可能会导致未来有更多的项目迁移到Git上。

而随着拥有分布式版本控制系统优势的Git的快速发展,越来越多的开发者准备从集中式版本控制系统SVN迁移到Git上,这其中,Git相对SVN表现出来的更有利于开发者版本控制管理的特点自然是最重要的原因。

最近(此前半年),Google Code允许项目在Git与Hg之间做出选择以作为其分布式版本控制系统(一开始只支持Hg)。从那以后,Git仓库不断增长,很多Hg仓库也已经迁移到了Git仓库上。在Google Code上搜索git会返回5m个结果,而搜索hg则返回16m个结果(Google在2009年4月就添加了对Hg的公开支持;这样,Hg已有2.5年的历史了,而Git在Google Code上才半年而已)。

Git vs. SVN

Atlassian去年收购了Bitbucket,除了一开始提供的Hg支持,Bitbucket也提供了Git托管。虽然Bitbucket并未透露使用这两种版本控制系统的项目数量,但搜索hg site:bitbucket.org会返回16m个结果,搜索git site:bitbucket.org则返回5m个结果,这个数量非常类似于Google Code(但BitBucket提供Hg仓库的时间要比Google Code长得多)。

因为从属于不同的集中和分布式模式,因此,从工作模式来看,Git和SVN存在着比较明显的不同,如下图所示。

无论你如何看待,分布式版本控制系统正在成为主流而非异类。现如今的开发者都生活在GitHub时代。

集中式版本控制系统工作模型

(文/InfoQ )    

分布式版本控制模型

从两者的工作模式可以看到,分布式相比于集中式的最大区别在于开发者可以提交代码到本地,每个开发者通过克隆(Git clone),在本地机器上拷贝一个完整的Git仓库。而SVN则必须将代码提交到中心控制器。而由此产生的差异性,则决定了Git和SVN的各自的特性。

安全性

首先在安全性方面,由于采用分布式系统,每个用户就相当于一个Git库的备份,同时,通过SHA1哈希保证数据的完整性,防止恶意篡改,因此,具有很高的安全性。而SVN由于采用集中式,因此,所有代码版本库均存储在中央服务器中,因此,存在很大的单点故障的风险,同时,当服务器端历史数据被篡改时,客户端难以发现。

分支功能

在分支功能方面,由于Git采用本质上指向Commit对象的可变指针,因此,便于查询和追溯分支间的提交历史,并能够支持双向合并。而SVN分支不支持提交隔离,虽然一次提交可同时更改主线和分支的内容,但无法查询和追溯分支间的提交历史。

发布控制

在Git中,可以设置只有发布管理员才有权限推送的版本库或者分支,用于稳定发布版本的维护,还可以设置只有项目经理、模块管理员才有权推送的版本库或者分支,用于整合测试,因此,发布控制相当灵活,而SVN并没有明确的发布控制配置,更多的还是依靠用户自己的习惯。

开发审核

在开发审核方便,Git支持团队成员自建分支和版本库。通过合并请求或从成员个人版本库、分支获取提交,从提交说明、代码规范等方面对提交逐一审核。而SVN则不具备这些功能。

合并支持

Git基于DAG(有向非环图)的设计比SVN的线性提交提供更好的合并追踪,避免不必要的冲突,提高了工作效率。而Git基于对内容的追踪而非对文件名追踪,所以遇到一方或双方对文件名更改时,能够很好进行自动合并或提供工具辅助合并。而SVN遇到同样问题时会产生树冲突,解决起来很麻烦。

因此,从以上的对比可以看出,Git相对于SVN具有不少的优势,因此,从SVN迁移到Git成为了众多开发者的选择。

从SVN到Git

那么,从SVN到底如何切换到Git呢?实际上,方法有很多种,也都并不是很复杂,其中,CSDN博主UrChen提供了一种切换的方法,只需要简单的几步,即可完成从SVN完美切换到Git。

1.使用git svn clone 拷贝SVN仓库

cd ~/test_repo

git svn clone file:///home/*/Desktop/SVN/svn_repo/ -T trunk -b branches -t tags

2.新建一个Git的bare仓库

cd ..

mkdir test.git

cd test.git

git init --bare

3.将Git的默认分支和SVN的默认分支trunk对应起来

git checkout trunk

4.将test_repo推送到test.git中

cd ~/test_repo

git remote add bare ~/test.git

git push bare

此时就完成了推送,可以删除test_repo了

5.将Git repo中的trunk重命名为master

cd ~/test.git

git branch -m trunk master

6.将SVN repo中的tags移动到git repo的相应位置

使用git svn clone导出版本库的时候会将svn中的tags保存成git中的tags/**,而并不是默认的tag,所以要进行移动。(注意:此脚本仅示例tag是单级目录的情况,如果 tag 是包含目录的两级或者多级tag,请自行重新撰写脚本)

cd ~/test.git

git for-each-ref --format=´%(refname)´ refs/heads/tags |

cut -d / -f 4 |

while read ref

do

git tag "$ref" "refs/heads/tags/$ref";

git branch -D "tags/$ref";

done

7.完成迁移,得到test.git

进入工作文件夹,执行

git clone ~/test.git

OK,大功告成,使用Git进行版本管理吧。

除此之外,还有几个问题需要说明:

1、通过git-svn工具可以在SVN迁移到Git上,保留仓库历史记录。

2、切换到Git后推荐策略建议采用长期分支、特性分支。

3、目前Git还没法做到像SVN中对特定文件夹的细分权限控制,但可通过分仓或建立多分支的方式引导用户使用。

4、切换到Git后遇到合并冲突时,分两种情况:

类型1:修改了同一个文件的同一行

解决方法:确认正确的修改,然后用命令行解决,示例如下:

类型2:文件被重命名为不同的名字(树冲突)

解决办法:确认哪个名字是正确的,删除错误的,示例如下:

DevCloud与Git

前面已经说过,华为软件开发云(DevCloud)中的配置管理服务全面支持Git,并对Git进行了全面优化。而实际上,这个配置管理服务就是面向软件开发者提供的基于Git的在线代码托管服务。对于管理员和项目经理,它提供了仓库管理、权限管理、成员管理、分支保护、安全管控及统计服务,对于开发者,它则提供了代码托管、代码仓库、在线客户端等服务。配置管理服务的产品架构图,如下图所示:

DevCloud的配置管理服务对Git的优化主要体现在以下几点:

1)支持跨地域协同开发、本地离线操作、代码合入评审。

2)支持在线客户端、代码在线浏览、修改、提交、在线创建分支、比较分支、新建合并请求。

3)具有代码加密传输、仓库权限管理、分支保护等多种安全措施。

4)提供了大量的仓库模板、通用模板,以方便开发者提高创建效率。

5)提供基于代码的统计分析、仓库提交信息统计、贡献者统计等相关统计数据。

总结

总之,从SVN切换到Git目前来看,是利多弊少,也是一个趋势,建议有条件的开发人员可以尝试一下,此外,DevCloud中的配置管理针对开发人员使用Git做了大量的优化工作,感兴趣的朋友也可以登录http://www.hwclouds.com/devcloud/网站下载试用,体验一把用优化了的Git进行版本控制的感受!

上一篇:没有了
下一篇:没有了

更多新闻推荐

Copyright © 2015-2019 http://www.77zhth.net. 美高梅官方网站66159有限公司 版权所有