Looking at the history of version control systems, or code management systems, it can be roughly divided into four periods, with the following mainstream tools corresponding to them:
-
1980: RCS
-
1990: CVS, VSS, Perforce
-
2000: SVN
-
2005: Git
Undoubtedly, Git is the mainstream tool used for source code management today, initiated by the father of Linux, Linus Torvalds. Before 2002, Linux developers around the world sent code diffs to Linus via email, which he manually reviewed and merged, resulting in very low efficiency, and community developers expressed dissatisfaction. Linus was strongly opposed to centralized version control systems like CVS and SVN, which had poor performance and required an internet connection to use. From 2002 to 2005, BitMover allowed the Linux community to use their commercial version control system BitKeeper for free, but in 2005, Linux developers attempted to crack BitKeeper, leading BitMover to revoke the usage rights. In the end, Linus spent two weeks writing a distributed version control system in C, which is Git. Therefore, Git was born to better manage the core code of Linux. Like Linux, it is also open-source and has developed rapidly over nearly twenty years with the continuous contributions of community developers.
Meanwhile, SVN, as the previous generation of version control systems, is gradually exiting the historical stage. This January, GitHub also announced that it will stop supporting Subversion (SVN) starting January 8, 2024.
For companies that have not used any code management tools, with no historical burden, they will directly choose Git. However, most teams engaged in embedded development are still using the previous generation source code management tool SVN, and now they need to consider the questions of Why and How.
1. SVN vs Git
The most direct way to consider whether to switch from SVN to Git is to compare the two.
To summarize:
-
Architecture
SVN has a centralized architecture, while Git has a distributed architecture. The diagram below describes their architectures.
However, it is not easy to understand the differences between the two from the architectural model. A reference to flexibility and a vivid example can help clarify their significant differences:
-
SVN is like live streaming; users must be online to watch (submit code).
-
Git is like cloud storage; users can download and view locally (local commits), edit, and share, and then sync back to the cloud when needed (remote sync).
Therefore, Git can meet development scenarios such as remote work and temporary disconnection from the code server, which, in a sense, aligns better with the future trend of collaborative work. It also allows developers to perform version control locally, enabling them to develop unstable features locally with the possibility of “taking back” changes, and once the features are relatively stable, they can be synchronized to the remote. This lays the foundation for collaborative development and prevents unstable code from affecting others.
If you are using SVN, to address the above issues, you would have to create multiple local folders to store temporary code copies, which is not elegant.
-
Security
Due to the differences in architectural models, the two also perform differently in terms of security and reliability.
Of course, the more copies Git has, the higher the reliability, but the greater the risk of data leakage, which poses challenges to data security. Fortunately, domestic companies pay great attention to data privacy and protection. Most traditional enterprises have implemented encryption and protection of internal system data through DLP (Data Loss Prevention) technology, such as tools like IP-guard, which are effective for both SVN and Git.
-
SVN has a single copy; unless the server has backups, if the server fails, the code data will be lost, making it less reliable.
-
Git has multiple copies; each developer has a local copy containing all historical records. Although it may not be the latest version, it is easier to recover in extreme situations, providing higher data reliability.
-
Permissions
SVN and Git also have significant differences in their permission models.
This difference arises from the design philosophies of the two tools, which may be the only reason SVN users are reluctant to migrate to Git.
Since SVN supports directory-based authorization and early practices lacked much modular design, SVN users habitually stuffed all components and related dependencies of an entire project into a single repository, following a large repository model and authorizing directories or entire repositories as needed. This has led to SVN repositories being generally bloated and large, exacerbating performance issues.
On the other hand, Git’s philosophy is modular, advocating decoupling, and follows a separate repository model. If the code is relatively independent in terms of business and functional logic and can be independently compiled, it should be managed and authorized in different code repositories. If the code has strong dependencies and cannot be independently compiled, it can be placed in one repository, but directory-based authorization is unnecessary because developers without permission for certain directories cannot verify whether their developed functions are correct through compilation, thus losing the meaning of collaborative development. Of course, some code management systems based on Git support write control over directories in the code repository, somewhat compensating for this lack of permission control.
-
SVN supports permission control over directories in the code repository.
-
Git only provides permission control over the entire code repository and cannot control permissions over directories within the repository.
-
Performance
Due to the differences in architectural models, the two also differ significantly in performance. As C++ developers would say:
-
SVN branches are value types; creating a branch is equivalent to copying code to another directory on the server, which is inefficient.
-
Git branches are pointer types; creating a branch only creates a pointer to the code commit record, which is efficient.
As a result, SVN users generally do not have multiple branches, because the more branches there are, the worse the performance. The limited number of branches means SVN users cannot achieve collaborative development; when multiple developers work on the same branch, the probability of conflicts increases, and they affect each other. The later submitter needs to resolve conflicts, and forcefully overriding can impact the earlier submitter, turning it into a competitive game. In embedded development scenarios, it is common to have multiple versions corresponding to a single firmware or customized versions for different chips and users, which necessitates the use of branches for management. However, as the number of branches increases, the issues of code synchronization and performance begin to emerge, leaving SVN users in a difficult position.
In contrast, Git relies on flexible and efficient branch management, combined with various branching strategies, to enable collaborative development among multiple people, distinguish code by environment and version, and ensure that general code remains synchronized across different environments and versions. The branching strategy itself also determines the standardization of the R&D process, which is a core concern for enterprises.
-
Experience
-
SVN has fewer commands, is easy to learn, and is simple to operate. The commonly used TortoiseSVN graphical client tool is often used for operations.
-
Git has many commands, is relatively difficult to learn, and is more complex to operate. Developers familiar with the commands prefer to use the command line, while beginners are advised to use graphical clients like SourceTree or Git plugins in mainstream IDEs.
From the perspective of learning and usage, the cost of Git is relatively high, but there are methods and tools to lower the threshold. Compared to the changes brought by architecture and models, the changes in operational experience seem trivial. On the other hand, Git is considered a basic skill for developers, as 94% of developers worldwide use or know how to use Git.
Moreover, because SVN supports downloading by file and is easy to operate, non-technical personnel such as product managers and project managers can easily use it, so many SVN users use SVN for document management, such as Word and Excel. In contrast, Git does not support downloading by file (partial cloning can achieve this, but it is slightly more costly for non-technical personnel); the entire repository must be downloaded, and the operation is more complex. Therefore, when these users migrate to Git, the management of old documents becomes an issue. For this issue, documents should be managed on file servers (FTP, SMB, NFS, NAS, etc.) or document collaboration systems (Wiki, Confluence, Tencent Docs, Feishu, etc.). Storing them on SVN was feasible in the past, but the centralized architecture requires online access, and large files exacerbate SVN’s already insufficient performance. Additionally, people now value collaboration in document management beyond just management, storage, and version control. Thus, if one decides to migrate from SVN to Git, the document management model also needs to be upgraded.
In summary, migrating from SVN to Git is advantageous as it aligns with the trend of technological development. Compared to SVN, which no longer has any official support, there are many mature tools and commercial products based on Git, such as GitLab, GitHub, Gerrit, and Gitee, which can provide better support for enterprises’ DevOps transformation. Furthermore, Git fundamentally solves the performance issues of SVN, enabling better collaborative R&D and facilitating the establishment of standardized R&D processes in enterprises. However, besides the differences in tools themselves and user experience, Git also differs in repository models, branching strategies, and authorization models, which can directly impact changes in the R&D process. What potential risks are involved, and how can they be resolved? This can be referenced in the essential code management solutions for embedded development engineers.