No basic learning of SVN (2): differences between CVs and SVN

I believe that you have read this blog on the basic learning of SVN (1): the use of SCM and SVN (basic), and have a certain understanding of version control, we should also know that SVN and CVs are two popular SCM tools. So what are the differences between the two tools?

 

1. Version Number

For example, our version library is a, which contains files A, B, and C.

In SVN, the version number of the new version is not for a specific file, but for the entire library. If you submit five or six times, file a may be different or the same, that is, version 1.0 and Version 1.1 may be the same. Because 6th submissions may be due to modifications made to file B or C. In CVs, the opposite is true. Each update may only modify the version number of the file, that is, the version 1.0 and 1.1 of File A must be different.

(Here, we can correct a concept. "file a's version 2nd" is incorrect. It should be "file a's 2nd modifications, that is, the second commit ")

SVN's global version number has brought many advantages to SVN: for example, to copy a directory or file, no matter how many files are involved, SVN does not need to execute the Copy command on a single file in sequence, you only need to create a pointer pointing to the corresponding global version number.

 

2. directory version control

Cvs can only control the version of files, but cannot control the version of directories, which leads to the loss of many functions of CVS:

1. No mobile operations

There is no move operation in CVS. When a file is moved manually, cvs can only notice that a file is deleted in one location, while
Create another file. Because it does not connect to two operations, it is easy to cause loss of the file's historical track. Therefore, when using CVS, you must carefully select the location of each file.

2. No RENAME operation

There is no RENAME operation in CVS. rename a file manually will lead to the loss of historical contact between the files before and after the name, and recording the history is the main purpose of version management.

3. No copy operation

There is no copy operation in CVS. For Human copying, only the increase of new files can be seen, rather than the relationship between the copied source file and the target file.

SVN largely avoids these shortcomings. SVN treats directories as a special type of files. When a subdirectory/file in the directory is deleted, renamed, or a new subdirectory/file is created, the contents of the Directory change. Therefore, SVN records the modification history of directories like the modification history of common files. When a file/directory is moved, renamed, or copied, SVN can accurately record historical contacts before and after operations. Similarly, like comparing different historical versions of a file, SVN allows you to compare different historical versions of a directory to clearly display the change history of the directory.

 

3. Submit atomicity

CVS and SVN are also used as SCM version control management tools. The Atomic submission of SVN is superior!

SVN submits a file. The submission becomes valid only when all file modifications are successfully written into the database. Once it is interrupted, SVN will automatically perform the "rollback" operation. The SVN mechanism ensures that all changes will either take effect in the database or not in the database. Due to the atomic submission feature of SVN and the global version number method, when the submission is successful, a unique and new global version number is generated, at the time of submission, the log information provided by the user is associated with the new version number for only one storage (unlike the file-based repeated storage of CVs ).

CVS uses linear and serial batch submission, that is, to execute the submission one by one in sequence. Each time a file is successfully submitted, A new version of this file is recorded in the version library. However, when batch operations are interrupted for any reason, the version library is often in an inconsistent state. In addition, CVS may cause inconsistency even if the batch submission is not interrupted: Assume that user a starts a batch submission that takes a long time to complete. At the same time, user B executes the cvsupdate operation. In this case, user B may obtain an inconsistent update, that is, user B obtains part of the modified file of user a through the "Update" operation.

4. Support for the change Set Concept

Because SVN submission is atomic, the unique global version number generated by each successful submission corresponds to all file modifications submitted in this batch, that is, a svn version number corresponds to a logical change set, which may correspond to fixing a bug or improving an existing function, or corresponding to the implementation of a new function. It can be said that a change set is the logical result of a software development activity. The change set can be used in other processes of Software Development through its corresponding version number (such as the software merging/integration process, software release management, change management system, and defect tracking system are referenced. Therefore, SVN abstracts version management from a simple, single file modification level to a development activity that is easier to understand and communicate with each other.

5. Differentiated Binary File Processing

CVS was originally designed to process text files (or ASCII files, source code files), store text files differently, compare old and new versions, and merge files. However, for binary files, CVS is obviously insufficient. In the version library of CVs, for the historical versions of binary files, CVS stores different versions independently and redundant, even if there are only minor differences between versions. Different from CVS, SVN only stores differences from previous versions after each submission, thus saving a lot of storage space. More importantly, when the client needs to obtain a new version, SVN only transmits the version difference, thus greatly reducing the consumption of network bandwidth.

 

After talking about this, it seems that it is all about the advantages of SVN. In fact, it is not so perfect. The following describes some of the shortcomings of SVN.

1. Support for Chinese path names

CVS: better support

SVN: to save the permission control file as svn-supported UTF-8 format

2. Correspondence between local files and libraries

CVS: many to many

SVN: a database can have multiple working directories, but a working directory can only correspond to one database. Although the location of the database can be changed, the requirements are strict.

3. Storage of files in the database

CVS: completely visible to the user and the client folder structure (except for files generated by CVS)

SVN: you cannot see the real content of the file.

 

I. Use of SCM and SVN (basic)