First, I show a fundamental standpoint, I personally prefer to use git, but this is just a personal preference. When we need a technical solution to bring the whole team, not by our personal preferences as a major factor in the decision, but should be sufficient to balance, the choice of the team, program the company more efficient. Set aside personal standpoint, rational assessment of the pros and cons, I might recognize is a senior programmer, architect or a duty.
The team I was, and now is the choice of technical solutions as a company-wide git version control system, we have a total of almost 20 programmers, using five or more programming languages, development of maintenance projects around the four, is a small start-up companies in research and development to upper mid-size businesses. Use a version control system git, before I joined the company, is already a fait accompli, I heard this, I was very happy, because I said, I like git.
On Friday, our new engineers to share in the weekly meeting git, a colleague challenging road, why git better than svn? This question, asked if I personally, I may be a lot of reasons, but, like my usual mode of thinking, to convince others, it must be given enough compelling reasons, can not use subjective factors to convince others , that will only lead to controversy.
For, "Why git svn better than" this issue, I really wanted to give a definite answer, but, in the course of my search for answers, the difficulties encountered. So, I try to stand in the position to give a negative answer, then we'll turn the debate, so there is the subject of this article.
What are the advantages of SVN in the end
Broad popular support. I started using version control system I use is already SVN, so, in the end you want to retroactively SVN start when, had to resort to Wikipedia, I found, the first official version of SVN, dating back to 2000 , fifteen years ago it has been history. Before github big hits, SVN basically in a position to dominate the world. Almost all companies are using SVN as version control system, internal, Google Code is set off a wave of open source software, for a time, almost programmers around the world, are using SVN.
I dare say that we are currently recruiting programmers, yet never used the SVN. This means that if companies use SVN, then the probability that they get started quickly, is very high. Now Chinese SMEs and start-ups, the degree of difficulty of hiring a programmer, I do not want to elaborate - who is responsible, who headaches - if you use SVN, then learning a version control system uses this kind of thing, you will not be the mind of a problem.
Excellent cross-platform support. Older kind of thing, is not always the disadvantage in cross-platform support this point of view, it will become dominant. Fifteen years, SVN almost gained excellent client software on all platforms. TortoiseSVN success of the Windows platform, almost needless to say, and even programmers think, is the TortoiseSVN SVN itself, a reference to a small turtle, each code will be agricultural heart smile. Also, SVN command line client itself, it has been very simple and easy to use. Cross-platform simply and without any place picky.
Easy to use. I personally believe that ease of use SVN is unmatched. My first year of the newly recruited staff of Tencent, programmers around, is to SVN as a cloud folder used. The entire department, only one repository, a project folder, all items inside the trunk code is still the need to open new projects in the trunk Riga a folder. Even if SVN is misapplied to such an extent, it still did not bring any major trouble throughout the development process, everything is in perfect order. You have to learn, that is, in a small turtle in the little mouse only.
Later, the department gradually expanded, increased documentation, in order to protect the document is not lost, the department set up their own operation and maintenance of a SVN server, so that all members of the non-programmers, all with SVN document management, variety of requirements, design draft, all with SVN management, the switching process hardly spend any time, it is simply to give some non-technical colleagues trained a little, everything is smooth exceptions. Let V., 60 non-technical people, all of a sudden were using SVN, which shows the simplicity of it.
Fully functional and stable. From the past seven years (in this case, 2015) development experience point of view, I have not encountered any R & D management model SVN can not handle. Especially in the next scene, Ltd. R & D team management in China. SVN itself recommended the development process model, has enough enough enough, trunk code for the trunk, branches for feature development, tag for publishing snapshots, everything is smooth and natural.
The team I was, after several years of exploration and running, has formed a very smooth smooth development process. There are new tasks to the open branch, every day, first thing in the morning, synchronization trunk change (sync trunk), the task is completed, branch testing, regression testing is completed after the trunk (reintegration), after completion of integration testing, the test is passed, play tag, then internal self-study on-line system, tag the whole amount of code release, the last head of the branch removed the used branch. Especially with the merge tracking features emerged after the 1.5 SVN, even conflict are very fortuitous incident.
SVN After about 15 years of research and development, dysfunction perfect, and very stable, you are familiar with the commands and parameters, it is almost always maintained that state you know well, no additional learning costs, the most valuable is, SVN has been continually updated, improve efficiency.
SVN git relatively speaking, what are the disadvantages?
The high cost of learning. Do not tell me that with open eyes, git learning is very simple ah, "is very simple to learn" This a subjective feeling, that you think is simple, you can only represent one person's feelings, if only one person the whole team, or you team pursued elitist culture, not elite recruitment is not the case, all of you, may feel that learning git is very simple. But if it is a newly entrepreneurial small companies, or SMEs operating for several years, considering the degree of talent itself acquired from the market, you have to consider their acceptance. Of course, companies can spend energy to training, but the training time and costs, in itself constitutes a "learning costs."
Poor cross-platform support. For Windows, especially in unfriendly. Note, however, Windows is still the most widely used operating system in the world, I believe, the majority of grassroots programmers still work in the Windows environment, git that almost intentional Windows unfriendly, I do not know what in the end is for. GitHub No matter what has been done, what has been done a variety of IDE, using git on Windows, its experience is still very indirect and inconvenient.
Bad abstract, complex structures. To make good use git, users must understand a few very special thing, a distributed structure, the other is the git version of the storage principle. This is no time to understand his people, the very friendly, you almost can not intuitively to use git, as almost always mess things up. In addition, the company's non-technical colleagues, almost impossible to use git work, such as our company's designer, trying to use git to manage the design draft, and collaborate, the actual experience is very bad, they will not even create a new repository . Not to mention the fact, also git binary file is not how friendly.
You can make things very bad. git entire system, giving users a great degree of freedom, many operations that we know are dangerous, but the operating system does not stop you. For example, you can put any branch to push any branch, for example, you are free to delete local commit history of commit, for example, you can put shared by many people to rebase branch out, you can do a lot of bad things incredible chaos care of the whole team speed, you can get into trouble, git itself does not provide any protection mechanisms.
Not a conclusion conclusion
I fully stand SVN's pro-pump angle to illustrate that, I will conclude that the above, SVN in some cases, actually more appropriate than git, and I think that this conclusion is also relatively fair. If the company R & D costs low, small R & D team, R & D personnel experience varies, should fully consider the direct use SVN, which could follow the development of your team, save a lot of time.
Of course, there is a factor to consider is the development of characteristic features and content development processes, whether high frequency coordination? Whether cross-company, cross-regional collaboration? Are massive R & D personnel involved in open-source systems? And in my experience, few companies have R & D team sorted these things take sides, so SVN naturally become more rational choice.