源码管理工具比较

源码管理工具,svn,cvs,hg,git，VSS

什么是源码管理工具

简单地说,源码管理工具是一种记录代码更改历史,可以无限回溯,用于代码管理,多个程序员开发协作的工具.

常见的功能有:

1.更新到任意一个版本(不用担心代码的修改错误,和丢失等)

2.日志记录(说明修改目的)

3.分支,标签(用于协作开发,和便于阶段性产品发布)

4.合并,比较(用于多人,多分支之间的代码合并,比对等)

为什么要使用源码管理工具

你可能会想,需求出来了,老大把我要做的功能告诉我,我去写代码就行,完事了,我再打包发给他让他加入到整个代码中,然后测试.有问题再反馈回来,我再修改,再打包.这样不是也挺好吗?

当然我要说,这样当然是可以的,但是如果你们要修改同一个文件怎么办?你们还得事先商量确定某个时间某个人不能修改等等.或者新建不同的名字的文件,最后由一个人来合并.

如果你的团队不是3,5个人,而是30,50人呢?你这样的沟通和重复性工作的成本会有多高?

于是聪明的程序员便有了版本控制的设想,继而有了源码管理工具的不断推陈出新.

如果你稍微开发过一个正式的项目,想必你对cvs,svn,hg,git这些也一定有所耳闻.

下面就简单根据我个人的一些项目经验来介绍下2类的源码管理工具.

源码管理工具介绍

简单地可以将源码管理工具分为两类:svn这样的集中式的,和hg这样的分布式的.

因为我个人对svn和hg比较熟悉,所以下面就以这二种具体的工具为代表来说明二者的优劣.

第一次接触源码管理工具就是svn,想着那时对于什么增量修改,历史记录等概念不清楚时,也曾在写了2小时的代码后,提交svn时失误而导致文件被删除的悲惨历史.惨痛的教训让我开始了系统地学习svn的过程,一天后,我明白了它的原理,这时会很晰明确地知道每个命令的结果,也会很清楚地知道自己怎样做才是最合适的.

简单总结一些best practice:

Check in early,Check in often(这个是很重要的,尤其是多个开发的团队,这样可以大大减少冲突的可能)

发现冲突第一时间解决(不能将冲突留给你的同事,发现了第一时间解决,如果需要要向冲突的相关同事沟通交流)

只提交需要提交的文件(一些临时文件不要提交,不能污染整个代码库)

熟悉常用的命令,如add/rm/up/ci/co/stat/merge/diff等

大致一个月后,我逐渐明白一个源码管理工具对于一个项目的意义和作用.自此后,我去公司实习我会第一时间询问他们是否使用源码管理工具,使用哪种工具.而对于自己的一些业余项目,我也通常是使用google code来管理起来,甚至当前的这些博客的源码(不过最近已经迁移到了hg的一个hosting service下,原因请参考下文).

到了去年的晚些时候,开始知道了分布式源码管理工具,了解了它与集中式工具的区别和优

势.也听到了一个小故事,

说是Linux的作者Linus大牛不满svn,于是自己花了一周(?抱歉具体时间记不得了)写了个分布式的代码管理工具,

于是就有了大名鼎鼎的git.

我们不去羡慕Linus大牛的英明神武(啊,真是牛啊!),我们来关心他的作品分布式代码管理工具.它与集中式的究竟有什么区别呢?

我以hg为例来说明与svn的不同:

1.每个work copy(也就你自己检出的代码)都具有完整的代码库信息,这也就是说:

对于检出的代码,我们无论是查看log,提交代码,或者删除等都是本地的操作,而无需与服务器打交道

2.只有push/pull两个操作(其它的初始化等操作不计入内)与服务器打交道,其它的日常操作都是本地

3.集中式的版本文件信息(所有的版本文件信息都位于项目根目录下的.hg目录下,而不像svn每个目录下都有一个.svn目录)

4.简单的忽略文件设置:.ignore文件中可以简单地设置你不希望提交到版本库的文件(支持通配符)

5.简单地说,我更喜欢hg的原因是,我无需再为了查看log而等半天(与服务器通信),这样大大地方便了网络不好,分布式的开发环境.

一些建议

我不说使用了代码管理工具的公司就是好公司,但是我肯定没有使用代码管理工具的公司肯定不是好公司.

同样,使用了代码管理工具的程序员不一定就是好程序员,但是没有使用代码管理工具的程序员肯定不是好程序员(至少没有经历过一个真正的多人协作的项目).

以我个人的项目经历,我极力向我的读者建议:

如果你没有使用过代码管理工具,请赶紧去学习一种(个人推荐hg).

如果你还使用的是svn,推荐你去尝试下hg.

如果你在做一些业余的项目,也建议你使用代码管理工具,即使是一个人.甚至你也可以将文档,知识管理,博客等也用代码管理工具版本化起来.

当然这里提到的几种代码管理工具都是有GUI版本的和命令行版本的,个人还是极力推荐使用命令行,为什么,可以参考这里如何提高程序员的生产率.

结论

代码管理工具对程序员而讲是必不可少的开发工具,选择一个合适的工具并且熟知它的常用命令,会让你的开发(你的团队的开发)变得事半功倍.

后记

推荐几个常用的hosting服务,常用的如下:

google code(支持svn,hg)

bitbucket(hg,极为推荐,免费提供1个private和任意多个public的代码库)

github(git)

当然上述的都是免费的服务,建议大家尝试下.

VSS、SVN、Clearcase，在此做一个小小的总结

一、Visual Source Safe(简称VSS)

VSS是微软的产品，是配置管理的一种很好的入门级的工具。VSS最初的名字叫Source Safe，是一家小公司的产品，92年曾经获了最佳小型管理工具奖，然后立即被微软收购。但是微软收购的只是source safe的Windows版本，在美国还有另外两家公司分别获得了继续开发和销售source safe的Mac版本和Unix版本的许可，在MS买进vss之后，基本上没有对vss进行任何的研发，MS内部自身也不用vss。

SourceSafe长得很象早先土气的文件管理器，的确难看。但是难看不碍事，SourceSafe的优点可以用8个字来概括“简单易用，一学就会”，这个优点是它老妈Microsoft遗传下来的，是天生的。虽然SourceSafe并不是免费的，但是在国内人们以接近于零的成本得到它，网上到处可以下载啊。当然Microsoft也不在乎这个小不点的软件，它属于“买大件送小件”的角色。如果你合法地得到Visual Studio，你就得到了免费的SourceSafe。

评价如下：

易用性：★★★★★

易学易用是VSS的强项，VSS采用标准的windows操作界面，只要对微软的产品熟悉，就能很快上手。VSS的安装和配置非常简单，对于该产品，不需要外部的培训（可以为公司省去一笔不菲的费用）。只要参考微软完备的随机文档，就可以很快的用到实际的工程当中。

功能：★★★

VSS的配置管理的功能比较基本，提供文件的版本跟踪功能，对于build和基线的管理，VSS的打标签的功能可以提供支持。VSS提供share（共享)、branch(分支）和合并（merge)的功能，对于团队的开发进行支持。VSS不提供对流程的管理功能，如对变更的流程进行控制。VSS不能提供对异地团队开发的支持。此外VSS只能在windows 平台上运行，不能运行在其他操作系统上。

安全性：★★★

VSS的安全性不高，对于VSS的用户，可以在文件夹上设置不可读，可读，可读/写,可完全控制四级权限。但由于VSS的文件夹是要完全共享给用户后，用户才能进入，所以用户对VSS的文件夹都可以删除。这一点也是VSS的一个比较大的缺点。

总体成本：★★★★

VSS没有采用对许可证进行收费的方式，只要安装了VSS，对用户的数目是没有限制的。因此使用VSS的费用是较低的。

技术支持：★★★★★