分布式与集中式版本控制工具.docxVIP

分布式和集中式版本控制工具-svn,git,mercurial???现象,近年来,我们对版本控制工具的关注点似乎正在改变.起初,我们主要也是唯一的目的就是对代码进行监控,使我们能够安全的返回到旧的版本,以便我们能够诊断代码中的问题.后来,我们的关注点更侧重于如何使人与人之间的合作更为顺畅. 这个关注点并不是要取代对代码的监控,而是以代码监控为基础,并建立于其上的.现在,我们又越来越关注使用这些工具来描述代码的变更,因此就出现了对于重写代码历史命令(history rewriting command)的需求.当然,对代码变更的描述也同样需要建立在前两种关注点之上.我们可以把版本控制工具的应用分为六个层次:0. 没有版本控制完全没有版本控制的解决方案,或者就使用一个共享的文件系统,并对其做定期的备份.一个开发人员,或者最多几个开发人员在没有工具的情况下共享代码,其面临的风险可想而知:在任何时刻,代码可能都是不兼容的.代码可能会由于开发人员的错误面丢失.如果开发人员想要改写覆盖他人所做的修改,那再容易不过了.1. 初步的探索开发人员拥有了网络上的工作空间,他们无法在线下工作.运行一次代码构建也许就意味着有时间可以去好好吃一顿了.重构即使能够进行,也慢的要死.checkout代码可能需要一整夜.checkin代码也很慢.没有原子提交.Branching和Tagging操作的代价昂贵.个人或是本地建立branch就意味着再次的checkout.集中式的,而不是公布式的.合并点的跟踪很慢或是根本无法使用.这时的工具还没有办法理解重命名的合并.代码库有时会崩溃,需要较高的专家/开发人员比例,如1:10.这时的工具有了基本的版本控制功能,如checkout,版本记录和锁文件.通常这就意味着开发人员在同一份代码上工作,而代码的同步就会依赖于每个人代码文件的锁状态.这种工具在扩展和长期工作上都会有问题.对资源的重命名难到几乎不可能完成.Branching和Tagging操作则会需要同时操作三份代码的权限,而且可能还需要一个宰好的或者两柱香.如, VSS.2. 笨拙开发人员有了本地的拷贝,并且可以在线下工作.本地的文件系统意味着构建的速度大大提升.重构的时间只够喝杯茶了.checkout的速度已经非常快了.checkin也许还是慢一点.仍然没有原子提交.Branching和Tagging代价仍然昂贵.集中式的,不是分布式的.合并点的跟踪很慢或是根本无法使用.没有办法合并重命名文件,需要在提交前使用一些扩展的跟进冲突解决机制.代码库有时会崩溃,专家/开发人员比例已经得到优化,如1:20.如CVS和TFS.3. 基本成型开发人员拥有本地拷贝并且可以在线下工作.在本地文件系统上可以进行快速的构建.可以快速的重构.checkout和checkin的速度都会非常的快.终于有了原子提交.轻量级的Branching和Tagging操作.基本的合并操作.个人/本地的branching操作仍然需要再次checkout.因为仍然是集中式的,而不是分布式的.基本的合并点追踪.没有办法合并重命名文件,需要在提交前使用一些扩展的跟进冲突解决机制.代码库有时会崩溃,专家/开发人员比例已经很低,如1:100.如Subversion.4. 有效并且可靠开发人员拥有本地拷贝并且可以在线下工作.在本地文件系统上可以进行快速的构建.可以快速的重构.checkout和checkin的速度都会非常的快.无操作的代码同步和更新非常的快速.终于有了原子提交.轻量级的Branching和Tagging操作.高级的Branching和合并操作.个人/本地的branching操作仍然需要再次checkout因为仍然是集中式的,而不是分布式的.完善的合并点追踪.合并重命名文件只能通过配置好的branch映射来实现,否则就需要在提交前进行修订.代码库很少会崩溃,专家/开发人员比例非常低,如1:1000.如Perforce.5. 高速,无形,高度可用开发人员拥有本地拷贝并且可以在线下工作.在本地文件系统上可以进行快速的构建.可以快速的重构.checkout和checkin的速度都会非常的快.无操作的代码同步和更新非常的快速.终于有了原子提交.轻量级的Branching和Tagging操作.高级的Branching和合并操作.非常高效的个人/本地branching操作.分布式的,而不是集中式的.完善的合并点追踪.无缝合并重命名文件,无需任何配置.代码库很少会崩溃,专家/开发人员比例几乎为零,如1:10000.如Git和Mercurial.通过前面版本控制工具的演化过程,我们基本上可以看到分布式工具的特点和优势了.相对于以往的客户-服务器端的集中式系统,它所采用的是一种P2P的方式.客户端不再需要从一个单一