SVN

SVN, short for Subversion, is an open source version control system that supports most common operating systems. As an open source version control system,Subversion manages data that changes over time. These data are stored in a central repository. The archive works much like a regular file server, except that it remembers every change to a file. This way you can restore the file to an old version or browse the history of the file. Subversion is a general-purpose system that can be used to manage any type of file, including program source code.

At the heart of centralized code management is the server, from which all developers must retrieve code before starting the day, develop it, resolve conflicts, and commit. All version information is stored on the server. Without the server, the developer basically can’t work. Here are some examples: workflow:

  • Download project team’s latest code from the server.
  • Go into your own branch, work on it, and commit code to your own branch of the server every hour (this is a habit that many people have. Sometimes you need to do this because you want to go back to the last hour, or see what code you changed in the last hour).
  • The end of the day is coming, merge your branch to the main server branch, the day’s work is done, and reflect back to the server.

GIT distributed Version Control System

Git is a free, open source, distributed version control system for agile and efficient handling of any project, small or large. Git is an open source, distributed version control system for efficient and fast version management of projects from the very small to the very large. Git is an open source version control software developed by Linus Torvalds to help manage Linux kernel development. The biggest difference between distributed and centralized is that developers can commit locally. Each developer can copy a complete Git repository on the local machine by git Clone.

Git Git

From the perspective of the average developer, Git has the following features:

  • Clone the complete Git repository (including code and version information) from the server to the standalone server.
  • Create branches and modify code on your own machine for different development purposes.
  • Commit code on a self-created branch on a single machine.
  • Merge branches on a single machine.
  • Fetch fetch fetch fetch fetch fetch fetch fetch fetch fetch fetch fetch fetch fetch fetch fetch
  • Generate patches and send them to the lead developer.
  • Looking at the lead developer’s feedback, if the lead developer finds a conflict between two normal developers (a conflict that they can work together to resolve), he will ask them to resolve the conflict before one of them submits it. If the lead developer can work it out on his own, or if there are no conflicts, pass.
  • In general, developers can use the pull command to resolve conflicts, and then submit patches to the main developer.

From a master developer’s point of view (assuming the master developer doesn’t have to develop code), Git has the following capabilities:

  • Check email or other means to see the submission status of the average developer.
  • Patch and resolve conflicts (either by yourself or by asking developers to resolve them and resubmit them later, or if it’s an open source project, decide which patches work and which ones don’t).
  • The results are submitted to the public server, and all developers are notified.

The difference between

  • The SVN is a centralized version control system, which has an inexact analogy :SVN = version control + backup server The SVN acts like an archive repository. It supports parallel reading and writing of files and versioning management of codes, including fetching, importing, updating, branching, renaming, restoring, and merging.

    Git is a distributed version control system with the following commands: Clone, pull,push, branch,merge,push,rebase. Git specializes in versioning program code.

  • Like SVN, GIT has its own centralized repository or server. However, GIT tends to be used in a distributed mode, where each developer chect out code from a central repository/server and clone his own repository on his own machine. It’s safe to say that if you’re stuck somewhere with no Internet connection, like on a plane, in a basement, in an elevator, etc., you’ll still be able to submit documents, view history releases, create project branches, etc. This may not seem like much use to some people, but when you’re suddenly in an environment without an Internet connection, this will solve your problems.

  • GIT stores content as metadata, while SVN stores content as files. All resource control systems hide meta information of files in folders like.svn,.cvs, etc. If you compare the size of the.git directory with the size of the.SVN directory, there is a huge difference. Because the.git directory is a clone repository on your machine, it has everything from the central repository, such as tags, branches, version records, etc.

  • Branches are nothing special in SVN, just another directory in the repository. If you want to know if a branch has been merged, you need to manually run a command like SVN propget SVN :mergeinfo to confirm that the code has been merged. Working with GIT’s branches, however, is fairly simple and fun. You can quickly switch between branches from the same working directory. You can easily find branches that have not been merged, and you can merge these files easily and quickly.

  • GIT does not have a global version number, and SVN has by far the biggest feature GIT lacks compared to SVN. As you know, the version number of SVN is actually a snapshot of the source code at any given time. I think it’s the biggest evolution from CVS to SVN. Because GIT and SVN are conceptually different, I don’t know what features in GIT correspond to them. If you have any clues, please share them in the comments.

  • GIT’s content integrity is superior to SVN’s: GIT’s content storage uses the SHA-1 hash algorithm. This ensures the integrity of the code content and reduces damage to the repository in the event of disk failures and network problems.

The advantages and disadvantages

Advantages and Disadvantages of SVN

SVN has good Support for Chinese, easy operation and easy use, which can be easily used by artists, product personnel, testers, and implementation personnel. Unified interface, perfect function, easy to operate.

Pros and cons of Git

For differentiated version management of program source code, the code base takes up very little space. Easy to branch code management. Does not support Chinese, graphical interface support poor, difficult to use. Not easy to popularize. Scope of application:

  • Applicable to different objects. Git is for developers involved in open source projects. They care more about efficiency than ease of use because of their high level. SVN, on the other hand, is suitable for the average corporate development team. Easier to use.

  • Use different occasions. Git is suitable for the development of a single project with multiple development roles over the Internet, while SVN is suitable for the development of multiple parallel projects coordinated by project managers within an enterprise.

  • The rights management policies are different. Git does not have strict permission management control, as long as you have an account, you can export, import code, and even perform rollback operations. The SVN has strict permission management. You can control the permission of a subdirectory by group or individual. Distinguish read and write permissions. More strictly, rollback operations are not supported. Make sure your code is always traceable.

  • Branches are used in different ways. In Git, you can only branch for an entire repository, and once removed, you cannot recover. On SVN, Branch can work for any subdirectory and is essentially a copy operation. So, you can create a lot of hierarchical branches, remove them when you don’t need them, and simply checkout the old SVN version when you need it later.

  • Based on the third point, Git is suitable for pure software projects, typically open source projects such as the Linux kernel, Busybox, etc. SVN, on the other hand, is good at multi-project management. For example, you can have one mobile project BSP/design document/file system/application/automated build script in one SVN repository, or five mobile project file systems in one SVN repository. N (number of projects) x M (number of components) repositories must be set up in Git. The SVN requires a maximum of N or m devices.

  • Git uses a 128-bit ID as the version number, and while checkout specifies the branch, SVN uses an increasing serial number as the globally unique version number to make it easier to understand. You can use Gittag to create literal aliases, but that’s only for special versions.

  • The typical development process of Git is to establish a branch, develop it, submit it to the local master, and delete the branch. The consequence of this is that the details of previous modifications will be lost. When you do the same with SVN, no details are lost. Here’s an interesting link that shows how git typically works: (Master at the core, constantly creating new branches, removing old ones):

  • Partial update, partial restore. The SVN creates a. SVN folder in each folder for management, so local update or restoration can be easily implemented. If you only want to update certain parts, SVN will do just fine. Git can also be restored through historical versions, but it is not easy to achieve a local restore.

SVN is a centralized version control system, which brings many benefits, especially over the older local VCS. Now, everyone can see to some extent what everyone else on the project is doing. Administrators can easily control the permissions of each developer. There are two sides to a story, good and bad. The most obvious drawback of this approach is the single point of failure of the central server. If it’s down for an hour, no one can commit updates, restore, compare, etc., and no one can work together during that hour. There is also the risk of data loss if disks on the central server fail and are not backed up or not backed up quickly enough. The worst case scenario is to completely lose all historical changes for the entire project, with the exception of some snapshot data extracted by the client, but this is still a problem, you can’t guarantee that all the data has been extracted. Subversion principle only cares about specific differences in file contents. Keep track of which files are updated each time, and what is updated in which rows.

The characteristics of Subversion are summarized as follows:

  • Each repository has a unique URL (official address) from which each user gets code and data;
  • Get code updates, also can only connect to this unique version library, synchronization to get the latest data;
  • Submission must have a network connection (non-local version library);
  • Submission requires authorization, if there is no write permission, the submission fails;
  • Submission is not always successful. If someone else submits before you, it will prompt “change based on outdated version, update first before submitting”… And so on;
  • Conflict resolution is a race for speed: quick, submit first and get away with it; Slow hands, after submission, may run into trouble with conflict resolution.

Git is a distributed version control system

Since its inception in 2005, Git has matured to a level of ease of use while remaining true to its original goals. It’s fast, perfect for managing large projects, and has an incredibly non-linear branch management system that can handle complex project development needs. Unlike SVN, Git records a version history and only cares if the overall file data has changed. Git does not store data that changes the contents of a file. In practice, Git is more like taking snapshots of files that have changed and recording them in a tiny file system. Each time an update is committed, it looks through the fingerprint information of all the files and takes a snapshot of the file, then saves an index pointing to that snapshot. To improve performance, Git doesn’t save the file again if it hasn’t changed. Instead, it only makes a connection to the last saved snapshot.