Why should we discard subversion?

I want to repost this article today. I have to complain about the disadvantages of subversion, So that I cannot continue to work.

 

Let's talk about the environment. We are currently working on a small project with few members. At the beginning, PM handed over version control to me. I tried to use mercurial, and my development switched before the company and home, And I found mercurial better, "Don't push to me, I will pull from you", the essence, of course, you can also push, when you want to submit to the central warehouse, you can push. Of course, the speed is extremely fast, because I only need the difference between the pull version and the version.

Later, although I spoke a lot with PM, it may be that my expression ability was limited, and finally I was changed to subversion by PM .. the current situation is that I copy the code every day and paste it at home. I found that the startup server reported an error. I still had to modify XX and continue to find the server reported an error. It turns out that xx forgot to copy it back. No language overnight. However, today's error is due to an annoyance and cannot be found at the moment ..

 

Let's take a closer look at the following article:

From: http://www.infoq.com/cn/articles/thoughtworks-practice-partiv

 

Subversion was our close comrade-in-arms. However, since some of our team members went to the United States a year ago, the relationship between us and subversion began to break down. First, after setting up the Subversion server in the United States, frequent operations by Chinese developers have become very slow. The problem can be identified by tracing the code history. However, due to slow network speeds, developers will spend a lot of time waiting for server response, instead of analyzing the problem. Second, due to the lack of IT infrastructure investment and sound backup policies, the team was unable to access version management servers from China several times due to network issues or server downtime, normal submission and update operations cannot be performed. The most serious problem is that the version management server experienced a fault before the release, and the data on the server had to be rolled back nine days ago, it brings great risks to the release.

 

From a symptom perspective, Version Management Servers are not local, which is the main cause of speed bottlenecks. In essence, version management tools cannot be well scaled Based on the team's scale and structure. For us, the ideal version management solution is to set up servers in China and the United States to accelerate the execution of each operation, and automatically synchronize servers to balance the speed and code integration requirements of the two locations. However, the use of subversion as a version management tool determines that the server can only be set up in one location. SVK can solve some problems, but it has too many defects and is inconvenient to operate. The backup problem we are facing is that in the Subversion design, all metadata is only stored on the server. Once an accident occurs on the server, the valuable information contained in the metadata cannot be restored. Previous lessons have made us realize that if we use subversion as a version management tool, we should not just be optimistic that the server will not go wrong. We must have a detailed and feasible backup plan to avoid risks through continuous backup.

These inherent defects of subversion make us look at DVCs (distributed version management tools). In this family, mature products include git, mercurial, and bzr. In contrast, mercurial has good support for Linux, Mac, and Windows platforms. It supports Web-based access to the code library and mature intellij and Eclipse plug-ins. Now, mercurial has become a winner, it has been in our team for more than one year. From 0.9.4 to 1.1.2, every version update has made us more and more fond of this well-designed product. So what is mercurial's victory over subversion?

 

 

Fast and reliable

Mercurial gave the team the first experience of being fast because the working directory of DVCs is the same as that of the central repository. It also saves all the metadata, subversion operations (such as submission, history tracing, and updates) must be performed over the network. Mercurial can perform operations on the local repository (figure-1) offline ).

Figure-1

By reducing communications with the central repository, mercurial accelerates operations and reduces the impact of the network environment on the team, meeting our needs. This increase in speed and reliability provides a pleasant working experience for developers who are dealing with version management tools at all times. In addition, a working directory containing all the metadata can become a backup warehouse (Figure 2-B) when a problem occurs in the central warehouse (Figure 2-C), and only one command is required to run the entire process.

Figure 2

In this way, during the repair of the central warehouse by the is department, the development team can still exchange and revise the backup warehouse, and the daily work can still be normally carried out without the central warehouse, after the central warehouse is restored, all revisions during the downtime will be synchronized to the central warehouse through the backup warehouse (Figure 2-D). This mechanism can be used as a backup solution for the finance and hardware facilities limited team. Even if the central warehouse is completely damaged, the loss is very limited, avoiding the risk of "all eggs in one basket" When CVCs is used.

Easy collaboration

In our daily work, we often use mercurial's flexible branch merge to share modifications and work together. When I launched a product in India a few months ago, I needed to install the development environment on a new workstation. Because the code library is large and the network speed is slow, it takes several hours to clone a central repository (Figure 3-a). Mercurial's flexibility allows me to point my workstation to a laptop with code already in place for cloning (Figure 3-B ), in a few minutes, the workstation completes all the cloning operations, and then points it to the central warehouse (Figure 3-C) to submit and update code normally, greatly saving time and improving efficiency.

Figure-3

In another scenario, because my team uses Linux as the development environment, we will submit the code locally on the Linux workstation when we are eager to verify that some features work properly on the Windows platform, next, point the working directory of the Windows workstation to the Linux workstation to obtain the update (Figure 4-B ). Then, verify the function on the Windows platform. If the function is faulty, you can fix the problem and submit the revision from the Windows workstation to the Linux workstation (Figure 4-C ), finally, the Linux workstation runs the test and synchronizes all updates to the central repository (Figure 4-D ). The distributed feature of mercurial allows the development team to share the revision flexibly and develop more efficiently.

Figure 4

Friendly to small steps forward

The existence of the local repository makes mercurial more friendly for small steps forward. A small step forward means that developers can modify a small amount of code and submit it each time without disrupting any existing functions. These two requirements pose a dilemma for developers who use centralized version management tools, "Do not destroy existing functions" and "modify a small amount of code each time and submit" mean there are fine-grained requirements for analysis convenience, and developers must master the incremental Object Modeling and reconstruction, database design, migration, and other technologies. It is difficult to make small strides to reflect the lack of experience and technology of team members. However, solving these problems is not an overnight task. The existence of local warehouses gives developers greater freedom, allow developers to submit frequently without worrying about whether or not each commit will not disrupt existing functions, and synchronize the Code with the central database when the Code has been submitted several times to a stable State. By using mercurial, the small step forward practice can be carried out by the team. After realizing the benefits brought by the practice, we can pursue a high-quality small step forward.

Low learning curve

The flexible branch merge policy of mecurial allows us to choose a very similar architecture (-1) to CVCs (centralized version management tools such as subversion and CVS, after changing the version management tool, the team can still work in a familiar environment. In the structure shown in (figure-1), the developer must first set up a central warehouse and then clone the working directory from the central warehouse. during the development process, the developer submits the revision to the local warehouse, finally, after the function is complete, synchronize all modifications to the local repository to the central repository. In addition to the last step, the remaining steps are exactly the same as that of CVCs. developers can quickly establish a preliminary understanding of the overall mercurial architecture. The basic commands of mercurial are very similar to those of CVS/subversion. teams familiar with CVS/subversion can still work in familiar command line environments. From the structure to the command, mercurial makes CVCs user-friendly and reduces the learning curve, allowing developers to easily take the first step from CVCs to DVCs. If you just want to try it out, or the company's policy does not allow you to migrate version management tools from subversion to mercurial, mercurial also provides the hgsubversion plug-in to choose from, it can use mercurial as the subverion client. In this way, you can retain the Subversion Version Management Server and use mercurial locally to enjoy the advantages of DVCs, this allows developers to securely transition to the DVCs environment.

Summary

There is no doubt that subversion is a very good version management tool, but it has its own applicability, not a silver bullet. Abandoning subversion is not because we are new technology fanatics, but because it cannot be scaled to adapt to the structural changes of the team. My suggestions for teams that want to try DVCs are as follows: decision makers should first identify the pain points of the team and have a clear understanding of the problem domain, rather than simply catch up with the technology trend, the second is to use it and accept it slowly. If the team only stops studying the theory and demonstrates various solutions, it will not be able to master DVCs and use it to improve the efficiency of the team, at last, the entire team needs to continuously learn the design ideas behind DVCs, and abstract the problem domains and use a wide range of plug-ins. This knowledge will directly or indirectly help the team improve the ability to manage code versions and manage code more effectively.

Thanks

I would like to thank my colleagues Yang Harda, Chu yuexin, Qiao Liang, and Chen Jinzhou for their selfless suggestions and help during my writing. My discussions with Yang Harda gave me a clearer understanding of DVCs theory. Chu yuexin and I reconstructed the illustrations together. Qiao Liang and Chen Jinzhou put forward many opinions and suggestions on the structure of the article.

This article shares my experience migrating from a familiar subversion to mercurial at work. In this process, I have made many mistakes and gained a lot of experience. I hope that you can learn from this article and learn about the value that DVCs may bring to your team from the practice of DVCs in our team, so that you can enter the DVCs field with confidence.

Author Profile

Hu Kai, an agile consultant at thoughtworks, has been engaged in the design and development of the continuous integration tool cruise and cruisecontrol for nearly two years. If you are interested in web development, agile practices, open source, and community activities, you can visit his personal blog to learn more.