Detailed version control the similarities and differences of sharp weapon git,svn and the applicable scope _ related skills

Using git soon, superficial understanding:

1) applicable objects are different. Git applies to developers who participate in open source projects. Because of their high level, they care more about efficiency than ease of use. SVN is different, it is suitable for the common company development team. Easier to use.

2 The use of different occasions. Git is designed for individual projects with multiple development roles over the Internet, and SVN is suitable for the development of multiple concurrent projects that are uniformly coordinated by the project manager within the enterprise.

3 The Rights management policy is different. Git has no strict rights management control, as long as there is an account, you can export, import code, and even perform a rollback operation. SVN has strict rights management and can control the permissions on a subdirectory by group and by individual. Distinguish between read and write permissions. More stringent, fallback operations are not supported. Guaranteed code can always be traced.

4 The Branch (branch) is not used in the same range. Git, you can only branch the entire warehouse, and once deleted, you cannot recover. In SVN, branch can be targeted at any subdirectory, which is essentially a copy operation. So, you can build very many, layered branch, and delete it when you don't need it, and then just checkout the old SVN version when you need it.

5 based on the 3rd, Git is suitable for simple software projects, typically some open source projects, such as Linux kernel, BusyBox and so on. Instead, SVN is good at multiple project management. For example, you can store a bsp/design document/File system/application/Automated compilation script for a mobile phone project in an SVN repository, or a file system that stores 5 of mobile phone items in SVN. You must establish n (number of items) *m (number of components) warehouses in Git. SVN only needs up to n or M.

6 Git uses a 128-bit ID as the version number, and checkout to indicate which branch, and SVN using an incremented serial number as the globally unique version number, more concise and understandable. Although you can use Gittag to create some literal aliases, it's only for special versions.

7 traceability, the typical development process for GIT is: Establish a branch, develop, submit to local master, delete branch. The consequence of this is that the details of previous modifications will be lost. And do the same thing under SVN, without losing any details. Here is an interesting link that shows the typical way to work with Git: (with Master as the core, constantly creating new branch, deleting Old branch):

Http://www.kernel.org/pub/software/scm/git/docs/howto/separating-topic-branches.txt

8 Local update, local restore. SVN because it is in the folder to build an. svn folder to implement management, so can be very simple to implement local update or restore. If you only want to update some of the parts, SVN can be very well implemented. At the same time the code is wrong, and can be a good local restore, of course, git can also be restored through the historical version, but not simple to achieve local restore.

SVN belongs to a centralized version control system

This has brought a lot of benefits, especially compared to the old-fashioned local VCs. Now, everyone can see to some extent what other people in the project are doing. Administrators can also easily control the permissions of each developer.

Things are both good and bad. The most obvious disadvantage of this is the single point of failure of the central server. If the downtime of one hour, then within this hour, who can not submit updates, restore, contrast, etc., also can not work together. If the disk of the central server fails and there are no backups or backups that are not sufficient in time, there is a risk of losing data. The worst-case scenario is a complete loss of all history change records for the entire project, with the exception of some snapshot data that is extracted by the client, but that is still a problem, and you cannot guarantee that all data is already being extracted.
The subversion principle concerns only the specific differences in the content of the file. Each time you record which files are updated, and what rows are updated.

The characteristics of subversion are summed up mainly by the following:

Each version library has a unique URL (the official address), where each user obtains code and data from this address;
Get updates to the code, and you can only connect to this unique version of the library, synchronizing to get the latest data;
Commit must have network connection (non-local version library);
Commit requires authorization, if no write permission, the commit will fail;
Submission is not always successful. If someone else submits it before you, you will be prompted to "change based on outdated version, update before submitting" ... Such
Conflict resolution is a submission Speed contest: Hands, first submitted, safe, Hange, after submitting, may encounter troublesome conflict resolution.
Git belongs to a distributed version control system
Since the birth of the 2005, Git has matured and perfected, while still retaining the initial set of goals while being highly usable. It is fast, extremely suitable for managing large projects, and it has an incredibly non-linear branching management system that can cope with a variety of complex project development needs.
Unlike SVN, git record version history is concerned only with the overall change in the file data. git does not save variance data that changes before and after the contents of the file. In fact, Git is more like taking a snapshot of a changed file and recording it in a miniature file system. Each time you submit an update, it will review all of the file's fingerprint information and take a snapshot of the file, and then save an index to the snapshot. To improve performance, if the file does not change, git will not save it again, but only one connection to the last saved snapshot.

In a nutshell, Git has the following characteristics:

The version library for each clone (clones) in Git is equal. You can create your own version library from any version of the library, and your version library can be used as a source for others, if you like.
Each fetch of git, in fact, is a full backup of the Code warehouse. Submission is done locally, you do not need to be authorized by others, your version library is your master, and submission is always successful.
Even based on the old version of the changes can be successfully submitted, the submission will be based on the old version to create a new branch.
Git's submission will not be interrupted until you are fully satisfied with your work, push to others or others pull your version library, the merge will occur in the pull and push process, conflicts that cannot be resolved automatically will prompt you to do it manually.
Conflict resolution is no longer like SVN's submission contest, but consolidation and conflict resolution when needed.
In short, the company's development team in the project development management, SVN is a better choice for team members to jointly maintain the company's central version.

If open source projects, Git is more appropriate, everyone can maintain their own version, while there is GitHub open source community support.