Talking about Version Control System

background

I think everyone has given files these names:

HelloWorld.java
HelloWorld_2018_04_05.java
HelloWorld_2018_04_06.java

When we use these files alone, we can manage the files in the above-mentioned way. However, if two people modify the file at the same time, the content modified by one of them will be overwritten by the content of the other. is what we don't want to see. For example, in the following code, you cannot simply use the HelloWorld written by Li Si to cover the HelloWorld written by Zhang San.

// 张三写的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 – Pessimistic Locking

Based on this, the Version Control System (VCS) was applied. At this time, VCS (v1.0) converts concurrent execution into sequential execution through pessimistic locks. It has the following functions: First, the file should be placed in On a server, it is convenient for users to upload or download files; secondly, when anyone wants to modify a file, they need to lock the file first checkout, and make it impossible for others to modify it through instructions; finally, when the modification is completed, the lock needs to be released , through the checkininstruction, a new version is formed and stored on the server side.
After using v1.0, Zhang San and Li Si need to compete for the lock. Assuming that Zhang San grabs the lock, Zhang San first uploads HelloWorld.java to the server to form a new version and releases the lock. Then, Li Si obtains the lock, Upload the code to the server for comparison and merging , and finally upload, and finally form the following code:

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 – optimistic locking

There are also some problems with VCS based on pessimistic locks. For example, Wang Wu only wants to learn HelloWorld and will not modify the file. When Wang Wu pulls the latest code from the VCS server, he also needs to perform locking operations; After the latest code, forgot to release the lock, making it impossible for other people who want to modify the code to modify it. In response to these problems, we replaced optimistic locks with pessimistic locks, and VCS evolved to version v2.0. The usual practice of optimistic locking is to add a version field to each table. Before the transaction modifies the data, the data is read first. Of course, the version is also read out, and then the read version number is added to the condition of the update statement. For example, the read version number is 1, we can write the statement to modify the data like this, update table set column = xx where id = 1 and version =1 , then if the update fails, it means that other transactions have modified the data in the future , the system needs to throw an exception to the client, let the client handle it by itself, and the client can choose to retry.
Taking HelloWorld as an example, Zhang San modified HelloWorld.java and successfully submitted it to the VCS server. At the same time, Li Si also modified HelloWorld.java. When submitting, the system will prompt "The version has been updated, please download the latest version again!". At this time, Li Si needs to pull the latest code from the server, and then merge the local code and the latest server code.

v3.0 – Multi-branch parallelism

We know that every software will have some hidden bugs, and users will put forward some new requirements in the process of using the software, which requires us to not only modify these bugs, but also complete the new function modules, and often modify the progress of the bugs Faster, and the cycle of adding new function modules is relatively long, which means that we cannot work in a code base. If we do this, we can't release the bug after fixing it, because the code containing the new function has not been completed!
Based on this, VCS has evolved to version v3.0, which supports multi-branch parallel development. For example, with the just-released product code in the Master branch, the bug modification team creates the branch-bug branch, and the new function team creates the branch-new branch. After the two teams complete their respective tasks, they merge their branches to the Master branch. middle.

v4.0 – Distributed

With the continuous increase of software functions, more and more teams have joined in, and at the same time, some new problems have arisen. Since the VCS server is centralized, there will be downtime from time to time, resulting in developers unable to submit code; In addition, some developers submit the code without testing the code well, which brings out a lot of bugs. In order to ensure the quality of the code, can someone review the submitted code before the code is submitted.
Based on the above two considerations, VCS has evolved to v4.0 version, which supports distributed, that is, each developer has a local code repository, and its architecture diagram is as follows. First, developer 1 and developer 2 clone from the official code base, and then make modifications; after the modification is completed, the code is not pushed to the official code base, but to their own local warehouse; project maintainers from the developer code warehouse Pull the modified code, and then decide whether to accept the modification; finally, the project maintainer pushes the modified code to the official code repository.

---

Welcome to the WeChat public account: Mu Keda, all articles will be synchronized on the public account.