• 我对软件系统中版本控制的简单理解
  • 发布于 2个月前
  • 144 热度
    0 评论
  • AUX
  • 7 粉丝 34 篇博客
  •   
我想大家都给文件起过这些名称:
HelloWorld.java
HelloWorld_2018_04_05.java
HelloWorld_2018_04_06.java
当我们单独使用这些文件时,按照上述方式可以很好的管理文件,但是,如果现在有两个人同时修改这份文件,那么,其中一人对文件修改的内容会被另一人的内容所覆盖,这是我们不希望看到的。譬如下面代码中,不能简简单单地用李四写的HelloWorld覆盖张三写的HelloWorld。
// 张三写的HelloWorld
public class HelloWorld{
  public void methodA(int arg){
    System.out.print("hi");
    System.out.print(arg);
  }
}
// 李四写的HelloWorld
public class HelloWorld{
  public void methodA(int arg){
    System.out.print("hi " + arg);
  }
  public void methodB(){
    int a = 1;
    int b = 2;
    System.out.print(a+b);
  }
}

v1.0--悲观锁
基于此,版本控制系统(Version Control System,VCS)就应用而生了,此时的VCS(v1.0)通过悲观锁将并发执行转换成顺序执行,它具有如下功能:首先,应该把文件放在一个服务器上,方便使用者上传或下载文件;其次,任何人想对文件修改时,需要先把这个文件加锁,通过checkout指令,使得其他人无法修改;最后,当修改完成之后,需要释放锁,通过checkin指令,形成一个新的版本,存放到服务器端。
使用v1.0之后,张三和李四需要争夺锁,假设张三抢到锁,张三首先将HelloWorld.java上传到服务器端,形成一个新的版本并释放锁,接着,李四获得锁,上传代码到服务器端进行比较合并,最后上传,最终形成如下代码:
public class HelloWorld{
  public void methodA(int arg){
    System.out.print("hi " + arg);
  }
  public void methodB(){
    int a = 1;
    int b = 2;
    System.out.print(a+b);
  }
}

v2.0--乐观锁
基于悲观锁的VCS也存在一些问题,譬如:王五只想学习下HelloWorld,并不会对该文件进行修改,当王五向VCS服务器拉取最新代码也需要进行锁操作;张三在提交完最新代码之后,忘记了释放锁,导致其他想修改代码的人无法修改。针对这些问题,我们将乐观锁替换成悲观锁,VCS演进到v2.0版本。乐观锁通常的做法是在每个表中增加一个version版本字段,事务修改数据之前先读数据,当然版本也顺势读取出来,然后把这个读取出来的版本号加入到更新语句的条件中,比如,读取出来的版本号是1,我们修改数据的语句可以这样写,update table set column = xx where id = 1 and version =1 ,那如果更新失败了,说明以后其他事务已经修改过数据了,那系统需要抛出异常给客户端,让客户端自行处理,客户端可以选择重试。
还是以HelloWorld为例,张三修改了HelloWorld.java,并且成功提交到VCS服务器中。与此同时,李四也修改了HelloWorld.java,提交的时候,系统就会提示"版本已更新,请重新下载最新版本!"。这时的李四需要重服务器拉取最新代码,然后把本地代码和服务器最新代码进行Merge。

v3.0--多分支并行
我们知道每一款软件都会潜藏一些Bug,并且用户在使用软件的过程中会提出一些新的需求,这就要求我们不仅要修改这些Bug,还要完成新增功能模块,而往往修改Bug的进度比较快,而新增功能模块的周期比较长,这就导致我们不能在一个代码库中进行工作,如果这么做,那么修正了Bug以后就没法发布,因为包含新功能的代码还没有完成!
基于此,VCS演进到v3.0版本,支持多分支并行开发。举例来说,以刚刚发布的产品代码在Master分支,修改Bug团队创建branch-bug分支,而新增功能团队创建branch-new分支,两个团队在完成各自任务之后,将各自分支Merge到Master分支中。

v4.0--分布式
伴随着软件功能的不断增加,越来越多的团队加入进来,与此同时,出现了一些新的问题,由于VCS的服务器是集中式的,时不时出现宕机情况,导致开发人员无法提交代码;还有就是有些开发人员没有对代码进行好好测试就提交了,带出了很多bug,为了保证代码质量,能不能在代码提交之前有人对提交的代码进行审查。

基于上述两方面的考虑,VCS演进到v4.0版本,支持分布式,即每个开发人员本地都有代码仓库,它的架构图如下。首先,开发人员1和开发人员2从官方代码库中克隆,然后进行修改;修改完成之后,并不是将代码推送到官方代码库,而是推送到自己本地仓库;项目维护人员从开发人员代码仓库拉取修改过的代码,然后决定是否接受这个修改;最后项目维护人员将修改完成的代码推送到官方代码仓库。

用户评论