Version Control Software

Recently, I joined a new team in the company and found thatSource codeThe version control software is CVs, and I feel a little backward, because I used SVN for version control all the time. I also like to toss about distributed version control software such as Hg and git. When chatting with a development manager, I learned why I have been using CVS instead of SVN or directly accessing Hg and git. The classmate told me modestly that CVS does have many problems, but it has been used for a long time. If it is changed to SVN, it seems that the benefits are insufficient.

However, it is interesting that this student uses cvs for management, that is, using CVS + local Hg. The specific method is that directory A uses both CVs and Hg.CodeIn directory B, modify Hg and directory B to push to directory A. in the case of frequent Hg push, after a function or bug is fixed, submit the change to the server through CVs. (The actual usage is more complex. It is also managed with Hg on another Linux machine, and then synchronized with directory A and directory B .)

The advantage of doing so is to avoid frequent input to CVS, ensure that each submission is a complete function or bug fix, and at the same time keep the history of each minor change locally. However, this is indeed a little tiring.

I have not carefully studied the specific differences between CVs and Svn, so I cannot persuade that student, and he may be more professional than me. Considering that I will work on CVs in the future, I searched the relatedArticleFind a well-written article. For more information, just paste it directly if you cannot find the source of the original article. If you know the source later, it must be shown.

 

The content of the post is as follows:

Comparison of CVS SVN VSS

I. Subversion contains most CVS Functions

As an override and release version of CVs, subversion aims to replace the popular CVS as a better version control software. Major subversion developers are industry-renowned CVS experts. Subversion supports the vast majority of CVS functions/commands. The command style and interface of subversion is very similar to that of CVS. Of course, the difference is the improvement of CVS.

Ii. Global version number

A new version and an incremental version number n + 1 are obtained. The version number is not for a specific file, but for the whole version library. Therefore, we can regard the version library of subversion as an array of a file system or file directory tree.

Technically, in subversion, "file Foo. version 5th of C "is incorrect. The correct statement should be:" file Foo. C has been modified 5 times in the version library, that is, what does it look like after 5 times of commit execution? ". Apparently, in subversion, the version library is modified five times before Foo. C content, and foo. the content of C is likely to be the same, because the 6th modification of the version library may only modify other parts of the version library, but does not modify Foo. c. On the contrary, in CVS, the foo. C version 1.1 and 1.2 are always different.

The global version number of subversion brings many advantages to Subversion: for example, to copy a directory or file, no matter how many files are involved, subversion 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.

Iii. directory version control

Cvs can only control the version of a file, but cannot control the version of a directory. Therefore, CVS does not have any concept of moving a file. When manually moving a file, cvs can only note that a file is deleted in one location and another file is created in a new location. Because it does not connect to two operations, it is easy to cause loss of the file's historical track. When setting the CVS repository, you must carefully select an accurate location for each file, because this location is almost always used after the configuration.

Similarly, because CVS does not record the version history of the Directory, CVS does not support Rename of the file. Rename the file manually will lead to the loss of historical contact between the files before and after the name, recording history is the main purpose of version management.

In addition, CVS does not support "copy" (copy) of files. For CVs, manual copying only allows you to see the addition of new files, the relationship between the copied source file and the target file cannot be recorded.

To sum up, the root cause of lack of support for "moving", "Renaming", and "copying" files is that CVS cannot record the version history of directories, these operations often occur in the current software development process, which is one of the main reasons why subversion is developed and replaced by CVS.

Subversion processes a directory as a special type of file (in fact, from the perspective of the file system, a directory is indeed a special type of file, when a subdirectory/file in the directory is deleted, renamed, or a new subdirectory/file is created, the contents of the directory will change ). Therefore, the Subversion records the modification history of the Directory like the modification history of a common file. When a file/directory is moved, renamed, or copied, the subversion can accurately record the historical contacts before and after the operation. Similarly, similar to comparing different historical versions of a file, subversion allows you to compare different historical versions of a directory to clearly display the change history of the directory.

Iv. Atomic submission

From the user's perspective, both CVs and subversion support batch submission of modifications to multiple files, but there are essential differences in implementation methods between them.

CVS uses linear and serial batch submission, that is, to execute the submission in sequence, one by one. Each time a file is successfully submitted, A new version of the file is recorded in the version library. When submitted, the log information provided by the user is repeatedly stored in the version history of each modified file.

The disadvantage of the CVS serial batch submission mode is that when batch operations are interrupted for any reason (typical reasons include network interruptions and client crashes ), the version library is often in an inconsistent state: only a portion of the files that should have been stored in the database are stored in the database. It is very likely that the latest version of the version library cannot be compiled smoothly. More seriously, as other users execute the CVS update operation, this inconsistency will spread across the development team quickly, seriously affecting the development efficiency of the team and posing a quality hazard. In addition, if the interruption of batch submission is not found in time, the development team will usually spend more time debugging and troubleshooting software.

CVS may cause inconsistency even when 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 CVS update 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.

Subversion completely eliminates the above drawbacks of CVS. No matter how many file modifications are submitted in batches, the submission becomes valid only when all file modifications are successfully written into the database. Otherwise, the submission is interrupted for any reason, the Subversion automatically performs the "rollback" operation. In other words, subversion ensures that all modifications take effect either in or out of the database, that is, the version database is not modified. This is the Subversion atomic commit (atomic commit ).

Due to the atomic submission feature of subversion 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 ).

5. Support the change Set Concept

Since all subversion submissions are atomic, the unique global version number generated by each successful submission corresponds to all files submitted in this batch, that is, A Subversion 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, subversion increases version management from a simple, single file modification level through logical abstraction to a development activity level that is easier to understand and communicate.

6. Differentiated Binary File Processing

For historical reasons, CVS is mainly an early stageProgramDesigned by members, cvs can effectively process text files (or ASCII files, source code files), and store different text files, compare old and new versions, and merge files; however, for binary files, CVS is obviously insufficient. In the version library of CVs, The only thing cvs can do for the historical versions of binary files is to store different versions independently and in redundancy, even if there are only minor differences between versions. For example, if a 10 m binary file (photo, graphic file, mechanical design file, electronic design file) is modified once a week, regardless of the size of each modification, only this file consumes more than 500 mb of storage space. In addition, each time the client obtains a new version of the file, it consumes 10 MB of network traffic.

For the current development team, whether it is software development, web site development, mobile phone and other electronic products development, version management is required not only for source code and other text files, we also need to manage requirements documents, design documents, Test Documents, user manuals, graphic and image files, mechanical/electronic design files, and many other binary files. CVS is obviously not a good choice.

Unlike CVs, subversion adopts a unified binary difference.Algorithm(Binary differencing algorithm), that is, the same difference comparison algorithm is used for text files and binary files, and stored in the version library in the same way: after each submission, the version Library only saves a lot of storage space compared to the previous version.

This binary difference algorithm is not only applied to version storage, but more importantly, subversion treats binary files and text files equally, when the client needs to obtain a new version (for example, execute SVN update), only version differences on the network are transmitted, thus greatly reducing the consumption of network bandwidth. For more details, see "VII. Two-way differentiation-compressed network transmission ".

VII. Bidirectional differentiation-compressed Network Transmission

As mentioned above, CVS cannot effectively differentiate binary files. For text files, CVS only supports one-way differentiated transmission: the transmission from CVS to the client is differentiated, that is, when executing CVS update, only the difference is transmitted from the server to the client; when executing CVS commit, regardless of the code changes, CVS needs to transmit all the content of the modified file from the client to the server. Instead, it cannot only transmit the difference.

On the contrary, both text files and binary files have two-way differentiated transmission, and the differentiated content must be compressed/decompressed: The difference between obtaining on the server side is obvious, similar to CVS; the secret to the difference between subversion acquisition on the client is that-Subversion implies a "read-only, clean" copy of each file in the client's work copy (this copy is hidden in the hidden directory. in SVN, this copy is usually invisible and has more advantages. For more information, see "12. More local/offline operations "), by comparing the user's modifications on the client and the implied copy, the Subversion obtains the difference that needs to be actually transmitted to the server, and compresses the difference before network transmission.

For CVs, the operation cost (network bandwidth consumption is the biggest operation cost) is proportional to the size of the modified file, but not the size of the modified file; for subversion, the operation cost is only proportional to the size of the modified file, but not the size of the modified file. Therefore, compared with CVS, subversion consumes less network bandwidth (it should be a good choice in the current computing environment to exchange client storage space for less bandwidth consumption !). Subversion is more suitable for geographically distributed teams that conduct collaborative development over the Internet (or wide area network)-centralized and single version servers, and widely distributed clients.

8. efficient and quick branch and baseline Creation

Both CVs and subversion Support Branch and tag. Through branch and merge, the concurrent development mode of large projects can be effectively supported. Through baseline management, you can accurately identify the versions of a group of files to effectively manage software releases and trace back to a group of files if necessary.

However, CVs and subversion differ greatly in the method of implementing branch and baseline. When creating a branch, CVS needs to perform operations on all the files in the branch in sequence, so the branch creation cost (mainly the time required to establish the branch, or the computing resources consumed) proportional to the number of files involved in the branch, the larger the project, the larger the version library, the more files, the higher the branch creation cost; the establishment of the baseline (TAG) is similar to this.

The Subversion branch and baseline are created by executing "copy: how do we manage the so-called "branches" and "baselines" When version management tools are not introduced? The answer is obviously "copy"-We create baselines through "copy" or "backup". Similarly, to support simultaneous development by multiple developers, we create a copy for each developer ". From this point of view, it is natural that subversion uses "copy" to create branches and baseline, which means "returning to simplicity.

Due to the global version number feature of subversion, the process of creating branch or baseline in subversion, or the "copy" Process in subversion, the real operation is to create a pointer (pointer) to a certain global version number in the version library, and you do not need to perform operations in sequence for a large number of individual files. Therefore, the cost of this operation is a small constant, independent of the project size, version library size, and number of files; and, no version redundancy storage is required for branch or baseline creation. The new branch or baseline does not occupy version library space, the subsequent bucket overhead of the Branch is only related to the modified size.

9. Integrate Apache Web server to provide more features

Through integration with Apache web server, subversion provides a version Library Access Mechanism Based on HTTP/HTTPS protocol to support secure access of subversion across the firewall. In addition, subversion can take advantage of more Apache features, including but not limited to: a wide range of Apache user authentication mechanisms (including user authentication through LDAP servers such as Windows Active Directory servers ), directory path-based fine-grained access control, compression/decompression of transmitted network traffic, and browsing the version library directory structure.

10. Support for WebDAV

Web-based Distributed Authoring and Versioning is a communication protocol based on the HTTP 1.1 protocol. it extends HTTP 1.1 and adds some new methods in addition to get, post, Head, and other HTTP standard methods so that applications can directly read and write to the web server, it also supports write locking and unlock, and supports file version control.

Microsoft Windows2000, XP, ie, office, and Adobe/micromedia DW support WebDAV, which greatly enhances the value and efficiency of Web applications. For users who need to publish a large amount of content, applying WebDAV can reduce their dependence on the CMS system and create content more freely. Easy upload and download.

Through integration with Apache web server, subversion supports the WebDAV protocol, allowing business users or non-technical users to easily access the Subversion version library without installing any version management client, does not change the existing usage habits of business users, and supports document reviews, modifications, and version control by distributed business users, extends the software development lifecycle from the development/technical team to all stakeholders of the project (stakeholder ), this solution avoids confusion and disorder in the delivery of documents via email, security vulnerabilities, virus attacks, overwriting or loss of historical versions, difficult auditing, and many other typical problems caused by Windows operating system sharing.

11. Better identification and handling of conflicts

Both CVs and subversion support concurrent development by means of branch and merge, and can automatically detect conflicts at the time of merge, and in the Merged Results, use <... >>>>>> Identify the merged conflict part.

In CVs, user negligence often occurs (for example, the user does not notice the conflict, or the user does not fully handle the conflict), but it still carries <... >>>>>> Files with conflicting identifiers are directly submitted (COMMIT) to generate junk versions in the version library.

Subversion effectively solves the above problems of CVS: Subversion records and maintains the file conflict state. This conflicting status mark is reset only when the user explicitly executes the svn resolved command, this file can be submitted, greatly reducing the number... >>>>>> The possibility of submitting files with conflicting identifiers directly.

12. More local/offline operations

As we all know, the working copy of the CVS client contains an implicit directory CVs, which records some management information required by the client. Similarly, the client copy of subversion also contains an implicit directory. SVN, which also records some management information required by the client, such as the version library URL and current access version number.

Unlike CVs, the subversion. SVN directory also contains a "read-only, clean" copy of each file in the working copy. Because of the existence of this copy, subversion can perform more local/offline operations than CVs, that is, some operations do not need to access the version database server, therefore, there is no need for a network connection from the client to the server, and of course no network bandwidth is consumed. This step enhances the friendly support of the subversion for the WAN.

Subversion:

SVN status-displays the local modification overview on the work copy;

SVN diff-displays the local modification details on the work copy and compares the content before and after the modification;

SVN revert-Undo local modifications on the work copy;

13. Version Management of symbolic links

In UNIX file systems, symbolic links (symbolic links, including hard links and soft links) are an important file system element. CVS cannot manage the version of a symbolic link; subversion can manage the version of a symbolic link.

14. Metadata Management

Compared with CVS, subversion adds a metadata management mechanism. That is, you can attach any "property" to the files or directories in the version library, and record the property change history, that is, manage the version of the element data. A Subversion attribute is a binary group of "attribute name/attribute value". For example, "bugnumber = 100" is an attribute and can be attached to version n, to indicate that version n has corrected the bug number 100.

The purpose of the Subversion metadata is to provide attachment information to meet the needs of process or process automation, so as to enhance the Subversion management capability and automation. Subversion itself stores some special information through "attributes. An example of using subversion metadata: You can create, access, and modify "attribute" metadata in batch script programs or subversion hook programs (hooks) to meet the process automation requirements.

Comparison of vss cvs on 15th

VSS is suitable for small teams and has basic configuration management functions. The biggest feature of VSS is its ease of deployment and quick start. The biggest disadvantage of VSS is security, directory sharing, and file storage. Of course, VSS can only be used in windows.

CVS has been familiar with and should be said to have distinctive features. First, CVS is an open-source software. Based on its long-term history, many versions have evolved and are suitable for different platforms. Therefore, there are a variety of CVS clients. Second, the deployment of CVS is a little complicated. This is a disadvantage for VSS. Finally, CVS is better than VSS in terms of configuration management.

Comparison between sixteen VSS and SVN

1. SVN supports renaming, which is very important for Java development.

To get better code, refactoring is often required during development. refactoring often involves file refactoring names, which are not supported in VSS renaming.

2. You do not have to lock it during development.

On the one hand, refactoring is not convenient. On the other hand, offline development is not allowed. SVN is different. You can take it home and continue development. After you come back, submit it.

3. multiple platforms.
Supports operations on multiple platforms

4. Better client support.
The VSS plug-in eclipse is not as useful as its SVN plug-in. A svn client tortoisesvn used in Windows is also easier to use than a vss client (VSS only provides a GUI client provided by Microsoft ).

5. Better Integration with peripheral tools.

A variety of peripheral tools (mainly on the server side) to meet a variety of needs. If necessary, you can also write plug-ins or management scripts, open architecture, and allow us to do so.

6. Convenient.

An example: when deploying an application, the previous method was to find a file modified in the project and update it to the server. Now you can run the svn Export command on the server, export the latest version of the code library to complete deployment (or replace it with the old version ).

7. both speed and stability look good.

It is worth learning about its management and how it works. VSS is a software that has been gradually abandoned. If time is not too much to use, you can spend time on the most worthwhile things.

 

Finally, I would like to add:

User and permission management

CVS: it is difficult for administrators to clearly understand the permissions and passwords of each user in a project. Users can only be managed in groups, and their passwords and permissions are unclear.
SVN: view and modify the configuration file.