Basic concepts of Version Control
This article mainly explains the principle of Version Control in theory. The specific operation commands on subversion will be mentioned in the next article. I personally think that understanding these basic concepts will help to better understand subversion version control.
Subversion applies to all types of file management and is not limited to programmers.
I. Version Library (the repository)The repository is the core of the version control system. It stores system data. Generally, it stores tree-like structure information (that is, hierarchical structure information of files and directories ). As shown in, the client connects to the repository to read and write files. When writing files, write operations on the client must be visible to other clients. When reading a file, the client needs to read the modification information of the file from other clients. This looks like a file server. The client connects to the repository and usually reads the latest file version. However, unlike the general file server, the repository not only can read the current version of the file, but also can read the historical version of the file.
Fig 1.1 typical C/S system
Ii. working copy is a copy of the remote version library file locally. Modifying the local copy does not affect the files in the version library.
Iii. Version model if the first mission of a version control system is to trace the digital information of different versions, its second mission is to cooperate in editing and sharing data, it is widely used in code version library management. 3.1) file sharing all version control systems face a basic problem: how to share information between users and how to avoid overwriting shared information between users.
For example, in the following example, there are two Project collaborators Harry and Sally who intend to edit file a in the version library. Suppose Harry first writes the modifications to the file to the version library to form the new version of the file ', then Sally also writes the changes to the file to the version library to form the new version of the file A', which causes Sally to overwrite the changes made by Harry. We need to avoid this situation !!
Figure 1.2 situations to be avoided
3.2) the lock-Modify-Unlock Solution uses the lock-Modify-Unlock model in many version control systems to enable collaborative work. In the lock-Modify-Unlock model, only one file can be modified at a time. This exclusive policy is implemented using locks. As shown in 1.3, Harry must lock the file before modifying it. If Harry locks the file, Sally cannot lock the file, sally can only read the locked file until Harry unlocks the file.
This model has several problems: 1) Locking files will cause management problems. Sometimes Harry forgets this thing after locking a file, Sally will wait until all the flowers are thankful. If Harry goes out for a mountain outing, Sally needs to ask the Administrator to unlock the file. This results in a lot of unnecessary time waste. 2) Locking files may cause unnecessary serialization problems. If Harry is only editing the first part of the file, but Sally is only editing the latter part of the file, their modifications to the file do not overlap, so they can be done at the same time. However, if the file is locked, another person can only wait. 3) Locking files creates a security illusion. For example, Harry locks file a while Sally locks file B. If file a and file B are mutually dependent, this is similar to a deadlock, and both files do not work.
3.3) copy-Modify-merge solution subversion. CVs and many other versions use the copy-Modify-merge model. In this model, each client contacts the project repository to obtain a local working copy ), then you can use your work copy to work simultaneously and modify the project file. Eventually, these work copies are merged to form a new and final version. The version control system assists in the final merge process. However, to ensure that the merge is correct, manual participation is required.
Figure 1.4 copy-Modify-merge Solution
If Sally's modification overwrites Harry's modification, it is called a conflict. It depends on the user to resolve the conflict. When Harry is preparing to submit, an error occurs because the version in the repository is inconsistent with the version previously read. In this case, Harry needs to read the latest file version from the repository and merge it with the local working copy to manually choose the conflicting part, whether to retain your own modifications or Sally's modifications is determined by Harry himself. Finally, she saves the merged files to the repository. One important factor in copy-Modify-merge is communication. If the communication between users is insufficient, the possibility of syntax and semantic errors will increase significantly. No system can force users to achieve perfect communication, nor can the system detect semantic conflicts. The Locking Scheme can avoid conflicts to some extent, but it is not safe; locking only reduces the efficiency.
