Distributed version control (end)

This article makes a simple summary.

Let's take a look at the comparison between DRCs and traditional SCM. Although DRCs has many advantages, it is impossible to completely replace the centralized SCM. After all, there are two completely different ideas.

I was optimistic that DRCs would replace traditional SCM, but this is just my personal experience. I can easily replace SVN with mercurial, but it doesn't mean it is suitable for everyone. Ling Hu pointed out that in their company, because there is a set of management tools and specifications on the basis of VSS, even if they know there is a better choice, it is unlikely to be replaced.

In addition to this situation, for the development team of the company model, it is still necessary to have a centralized management constraint on the source code. In this case, the centralized SCM still has a lot to do.

But for individuals, small teams, distributed teams, especially open-source development teams, DRCs still has the incomparable advantages of traditional SCM. In addition, many advantages of DRCs are also worth the reference of traditional SCM. For example, flexible and convenient branch/merge functions. The branch Merge function of SVN is too weak, and we know it once used.

Then compare bazaar and mercurial. Although I have mentioned it in the previous articles, I will summarize it here. In terms of operations on common functions, the two methods are basically the operations of traditional SCM, including almost identical operation commands and parameters, and similar configuration file projects. So let's not talk about this. Let's just talk about the different aspects of the two.

Bazaar has the advantage of smart renaming, which is advantageous in renaming directories in large projects, but this function is not commonly used after all. The Rename of mercurial is the same as that of traditional SCM. It is deleted and added again. Mercurial wins bazaar in terms of operability, and mercurial wins in terms of ease of Installation-bazaar needs to install additional dependent software packages on its own when using SSH.

The biggest difference between the two types of DRCs lies in the remote repository operations. Both support remote repository access through HTTP and SSH, but the implementation methods are different.

The HTTP Method of bazaar is simple. You only need to configure a Directory Project in the web server to allow access to the. bzr directory in repository through HTTP. However, Bazaar only provides read operations in http mode, which is a disadvantage.

The need for remote repository read and write operations, or the SFTP--FTP over SSH -- method. Of course, the implementation of this access method is also very simple, as long as the server supports SFTP. You do not even need to install bazaar on the server. All remote repository operations (including initial creation) are performed on the client.

Mercurial is troublesome. The premise of its remote repository operation is that a mercurial must be installed on the server, and the remote repository must also be created on the server using the init command.

The first is the HTTP method, which requires the server to run the serve command to provide the HTTP service on a specific port, and then the actual Web server uses mod_proxy and other methods for proxy. The cost is that additional resources need to be consumed on the server, but the advantage is that more powerful functions can be provided, rather than reading and accessing as much as bazaar does.

But mercurial's SSH method is a little inconvenient. Of course, it is also because of windows, and it is very convenient in Linux. For details, see the previous article.

The conclusion is that there is no conclusion ~~ Rz

SVN, bazaar, and mercurial are all very good. Which of them depends on your actual situation. In addition, there will be no major conflicts even if three are used together.

My personal recommendation is: SVN + any one of your favorite DRCs is a good solution-use DRCs for small-step iterative development and branch or merge as needed, submit Svn in a convenient way (such as a fixed cycle.