Version Control tool comparison-cvs,svn,git

First of all, several versions of control software comparison of the important basis, more detailed comparison please refer to the link in the article:

* Repository Model (Repository models): Describes the relationship between multiple copies of the source repository, with both client/server and distributed modes. In client/server mode, each user accesses the main repository of the server through the client, and each client only needs to save a copy of the file it is interested in, and changes to the current working copy (working copy) will only be visible to other users after committing to the server. In distributed mode, these source repository replicas are peer entities, and the user's machine has a history of the local repository, out of which to save their working copy.

* concurrency mode (Concurrency model): Describes how to manage this conflict when making changes or edits to the same working copy/file to avoid generating meaningless data, with exclusive lock and merge mode. In exclusive lock mode, only the user who makes the request and obtains the current file exclusive lock can make changes to the file. In merge mode, users can edit or change files at will, but they may be notified at any time that there is a conflict (two or more users editing the same file at the same time), and the version Control tool or user needs to merge the changes to resolve the conflict. As a result, almost all distributed version control software uses a combined approach to resolve concurrency conflicts.

* History Model: Describes how to store changes to files in the repository, with snapshots and change sets in two modes. In snapshot mode, the repository stores the working copy before and after the change, and in the change set mode, the repository saves only the changes that have occurred since the change occurred, in addition to saving the working copy of the change.

* Scope of Change: Describes whether the version number is for a single file or the entire directory tree.

* Network Protocols: Describes the network protocol used for synchronization between multiple repositories.

* Atomic commit (Atomic Commit): Describes the ability to guarantee that all changes are committed or merged, or that no changes will occur, when committing changes.

* Partial cloning (partial checkout/clone): Supports copying only specific subdirectories in the repository.

Name	Version Library model	concurrency mode	Historical mode	Scope of Change	Network protocol	Atomic Commit	Partial cloning
Cvs	Client-server	Merge	Changeset	File	Pserver,ssh	No	Yes
Svn	Client-server	3-way Merge, recursive merge, octopus merge	Changeset and Snapshot	Tree	Custom (SVN), custom (SVN) over SSH, HTTP and SSL (USINGWEBDAV)	Yes	Yes
Git	Distributed	Merge or lock	Snapshot	Tree	Custom, custom over SSH, rsync, Http/https, email, bundles	Yes

There is a certain understanding of versioning, and it should be known that SVN and CVS are the two most popular SCM tools. So what's the difference between the two tools?

　 1, version number aspects

For example, our repository is a, which has file a,b,c.

In SVN, the version number of the new version is not for a particular file, but for the entire library. Submitted 5 times and submitted 6 times, file a may be different, it may also be the same, that is, version 1.0 and 1.1 may be the same. Because the 6th commit may have been modified because of file B or C. In CVS, instead, each update may only modify the version number of the file, that is, the 1.0 and 1.1 versions of a file are definitely different.

(to correct a concept here, "the 2nd version of document A" is wrong, it should be "the 2nd modification of file A, i.e. the second commit")

SVN's global version number brings many advantages to SVN: such as copying a directory or file, no matter how many files are involved, SVN does not need to execute a copy command on a single file sequentially, just need to create a pointer to the corresponding global version number.

　　 2. Version control of the catalog

CVS can only version files, not version control of the directory, which causes CVs to lose a lot of functionality:

1) No move operation

There is no move in CVS, and when it comes to file movement, CVS can only notice that a file is deleted in one place and another is created in a new location. Because it does not connect two operations, it is also easy to lose the file history track. So when using CVS, the location of each file must be carefully chosen.

2) No rename operation

CVS does not rename (rename) This operation, the artificial renaming of the file will make the file before and after the naming lost historical links, and record history is the main purpose of version management.

3) No copy operation

There is no copy (copy) operation in CVS, and a man-made copy can only see the addition of new files in the case of CVS, not the connection between the copy source files and the target files.

While SVN avoids these shortcomings to a large extent, SVN handles the directory as a special kind of file. When subdirectories/files in the directory are deleted, renamed, or new subdirectories/files are created, the contents of the directory change. As a result, SVN records the history of changes to the directory as it records the changes in the normal file, and SVN can accurately record the history of the operation before and after a file/directory move, rename, or copy operation occurs. Similarly, as compared to different historical versions of a file, SVN supports comparisons of different historical versions of the catalog to clearly illustrate the history of the directory changes.

3. Atomic Submission

CVS and SVN are also used as SCM version control management tools, and SVN's atomic submission is outmanoeuvred!

SVN commits the file, and the commit becomes valid only if all of the file modifications have been successfully put into storage. Once interrupted, SVN will automatically perform a "rollback" (rollback) operation. This mechanism of SVN ensures that all modifications are either put into effect or not in storage. Because of the atomic commit feature and the global version numbering of SVN, a unique, new global version number is generated when the commit is completed successfully, and the log information provided by the user at the time of submission is associated with the new version number and is stored only once (as opposed to the CVS-per-file repeat storage).

I was the first to use mercurial, git this kind of system. (It's already hundred percent git.) ）
After using git, I was exposed to SVN and found some very big differences. Here are some of my main reasons for abandoning SVN and using Git.

1. Speed:
Cloning a completely new directory, in the same five (only five) branches, SVN is the simultaneous reproduction of 5 versions of the file, that is, repeat the same action five times. Git just gets the elements for each version of the file and then loads only the main branch (master). In my experience, cloning an SVN that has nearly 10,000 commits (commits), five branches, and about 1500 files per branch, consumes nearly one hours! And Git only uses a 1 minute clock!

2. Version library (repository):
As far as I know, SVN can only have one designated central repository. When there is a problem with this central repository, all work members are paralyzed together until the repository is repaired or the new repository is set up.

And git can have an unlimited repository. Or, more correctly, every git is a repository, the difference is whether they have an Active Directory (git working tree). If something happens to the major repository (for example, the GitHub repository), the working members can still submit their own local repository (locally repository), waiting for the major repository to recover. Work members can also be submitted to the other repository!

3. Branch (Branch)
In SVN, the branch is a complete directory. And this directory has a complete actual file. If a working member wants to open a new branch, it will affect the world! Everyone will have the same branch as you. If your branch is used for sabotage (security testing), it will be like an infectious disease.

With Git, every working member can open an unlimited number of branches in its own local repository. Example: When I want to try to sabotage my own program (security testing) and want to keep the modified files for later use, I can open a branch and do what I like. There is absolutely no need to worry about obstructing other working members. As long as I do not merge and commit to the major repository, no working member will be affected. When I don't need this branch, I just have to delete it from my local repository. No pain, no itching.
Git's branch name can be used with a different name. For example: My local branch is named testing, and the name in the main repository is actually master.
Most notably, I can open a branch at any of the commit points in git! (One method is to use Gitk–all to observe the entire commit record, and then open the branch at any point.) ）

4. Commit (Commit)
In SVN, when you submit your finished product, it will be recorded directly to the central repository. When you find that your finished product has a serious problem, you can't stop it from happening. If the network is interrupted, you simply can't submit!

And the Git commit is entirely a local repository activity. And you just "push" (git push) to the major repository. Git's "push" is actually doing "sync".

5. Re-establishment of the starting point (Rebase)
I did not try in svn, I do not know if there is such a function.

In Git, if you want to set up someone else's latest commit as the starting point for this branch, just execute git rebase branch_name. The difference between this and merge is that the merge will be considered up-to-date depending on the time of the modification, and rebase will ask you to resolve the conflict where both sides have changed (conflict).

A-B-E
\-c-d
A-B-E
\-c-d

6. System files
SVN will be placing an. svn in each directory. If you want to remove these. SVN is very tired.
Git will have a. git directory at the beginning of the directory, and. Gitignore.

It's easy for me to manage a git repository.

Version Control tool comparison-cvs,svn,git