Distributed version control system mercurial (1): basic functions of mercurial

Version Control System (Version Control System/Revision Control System), or source control system (VCS), is one of the most commonly used tools by software developers, because VCs are so commonly used, it is necessary to take some time to understand it.

 

• The distributed version control system (DVCs) is relative to the centralized version control system (CVCs). For example, the most popular SVN and VSS are typical CVCs. If you have used SVN or VSS, you can easily understand what it is called "centralized ". CVCs refers to the working model where only one data warehouse is stored on one server and all clients are connected to this server to read and write data warehouses. The DVCs model is not the case. Each terminal has a complete data warehouse. All terminals are equal and there is no unique "server ". All terminals can exchange data freely.

DVCs can easily simulate the way CVCs works. You only need to specify any terminal as the server and require everyone to push the changes to this server, and everyone can obtain updates from this server. Compared with CVCs, DVCs has the following advantages:

A) more secure code management.
In SVN, each submission means that the official code is changed. You can view the submission immediately, and may directly affect the running system (someone may copy the update to the server), which leads to a series of problems. The first problem is that someone may accidentally submit incorrect and unreliable code. Second, this causes the programmer to dare not easily check in the changes. When the program takes a long time and a lot of modifications, all the modifications are not protected by VCs, which is very dangerous, it does not match the original intention of using VCs.

In DVCs, it is different because it is first submitted to the local warehouse, so programmers can try to submit changes to the data warehouse without worrying that this will affect others or systems, this can fully protect all versions of code generated by programmers during the development process. This feature is particularly important during long-cycle development.

 

Although the branch Function in SVN can achieve similar purposes, branch merge operations are complicated and prone to conflicts. As a result, many branches should be used but are not used.

B) Get rid of the limitations of the network and complete the work at any time.
In SVN, because there is only one central repository, any actions that need to be communicated with the repository (such as querying historical versions, submitting changes, and so on) must be connected first. In some cases, this constraint is inconvenient. In DVCs, you can communicate seamlessly with the data warehouse at any time, and programmers can submit new changes to it without interruption, you can also query the historical versions of a file when the network is completely disconnected.

C) more intelligent code merging.
When two people work on the same code, the modifications made by the two may conflict. However, when a new SVN change is submitted, SVN can only view the final version. As a result, SVN cannot automatically merge some files with great differences, manual merge is time-consuming and labor-consuming. In mercurial, when two different versions need to be merged, DVCs can use all the modification history of this file to restore the entire modification process step by step, mercurial's merge capability far exceeds SVN, so in mercurial, there are very few problems with manual merge.

D) faster response speed. Because various daily operations are performed on the developer's local machine, the operation response speed of DVCs is much faster than that of any CVCs.

In addition, DVCs is especially suitable for personal projects, because DVCs is naturally good at managing local data warehouses, unlike CVCs, which requires a server and a client.

Therefore, the distributed mercurial structure has all the advantages of SVN, and is more reasonable and effective than SVN.

Currently, DVCs mainly includes two types of software: mercurial and git. The original author of git is Linus, which is written in C language and has better running performance than mercurial (mercurial is written in Python, naturally, performance cannot be faster than GIT), but Linus and the initial development team did not intend to develop the Windows version of git, So git itself does not support windows, later, a msysgit project transplanted git to the Windows platform, and a tortoisegit client was developed, making git easy to use in windows, however, when I was using mercurial, which was compatible with the operating system due to multiple serious faults in a row, I suspect it was not mature enough in windows. Mercurial refers to mercurial. Therefore, mercurial uses the mercurial chemical element symbol Hg, Which is why its graphic terminal is called tortoisehg rather than tortoisemercurial.

Here (http://hgbook.red-bean.com/read/) has a complete mercurial document that describes the various details of mercurial, but since it is in English, I will briefly list the basic usage of mercurial.

First, download and install a tortoisehg with mercurial (http://tortoisehg.bitbucket.org/), tortoisehg is a graphical client integrated with Windows Explorer, which is very similar to tortoisesvn. This installation package integrates the mercurial main program, so you only need to install this one. (Mercurial does not need a server)

After the installation is complete, Open Windows Explorer and right-click any location to view the tortoisehg menu as follows:

Here, you need to set the user information first, because you need to know the user name to record the history when submitting mercurial, so you must first configure the user name. click global settings in the menu, and on the commit subpage in the pop-up options window:

The username format is generally "name <email>". You can save it after writing it.

The clone command is used to copy a data warehouse from other locations, and the create repository here is of course to create a warehouse in the current folder. Here we create a warehouse first.

Alternatively, you can use the mercurial command directly without using the tortoisehg graphic interface.

In Windows 7, there is a hidden right-click menu. When shift is left blank, several items are added to the right-click menu, one of which is open command here, this opens a cmd command window. The path is the current folder. directly enter the command Hg init to create the data warehouse.

(I didn't like to use commands in the past, but after using mercurial, I found that using commands is not troublesome, and often it is more comfortable than tortoisehg)

 

After the data warehouse is created, right-click again and you will find that the Hg commit option is added to the first-level right-click menu, while a large number of available commands appear in the subitem. These do not need to be dealt with for the moment.

Create a text file, click Hg commit, enter a comment (mercurial requires that comments must be written each time), and click Submit.

Note that the file list on the left must be checked first. Because the file is added to mercurial, you must first execute the Add command before commit can be reflected in this graphic interface, that is, first check the left and then click commit.

If you use the command, enter:

Hg add

Hg commit-m "some comment here"

The first line of Hg add will mark all new files as requiring mercurial for tracking management, and the second sentence is to submit changes to the data warehouse.

 

Note the update command. The update of mercurial differs greatly from that of Svn in terms of actual effect. Update is used to make the working directory consistent with the local data warehouse. Therefore, if you are a single-user project and always submit modifications in the working directory, they must be completely consistent and the update command will never be executed. (This is also about why tortoisehg regards the update command as a level-2 command rather than a level-1 menu command like commit) when should I update it? Let's take a look at push and pull.

 

Assume that the repository we just created is located at D: \ repo1. Run the command Hg clone D: \ repo1 D: \ repo2, or click Clone on tortoisehg to perform the corresponding operations (the graphic interface is no longer one by one, in this way, a new repository repo2 is created, which is exactly the same as repo1. Now I have submitted some other changes to repo1. Obviously, repo2 is still in the clone status, and the latest modification to repo1 is unknown. If you want repo2 to be updated to the latest status of repo1, you can perform the following operations:

1. Push. Push, as its name implies, means to push data from repo1 to repo2 without any action. Run the command Hg push D: \ repo2 in the repo1 directory. Or click syncronize of tortoisehg and click the push command in the synchronization window:

(I think this operation is more convenient ...)

The path after the push command is not required. Each data warehouse can have a default remote warehouse. If repo1 sets the default remote warehouse to repo2, you only need to execute Hg push. When the clone command is executed, the source warehouse is set as the default remote warehouse. Therefore, you can directly execute Hg push or Hg pull in repo2, and the data is automatically synchronized to repo1.

Because repo1 does not know the existence of repo2, if you need to manually set the default remote repository, perform the following operations:

Right-click tortoisehg and choose repository settings,

Click Edit file to change default to the desired path.

After modification, you can directly execute Hg push without writing Hg push D: \ repo2.

2. pull. pull means pulling, that is, the updated warehouse actively pulls data from the remote warehouse. in this example, run Hg pull in the repo2 directory. because repo2 is cloned from repo1, repo2 has automatically set repo1 to the default remote repository and does not need to write Hg pull D: \ repo1.

 

Therefore, the repo2 Data Warehouse can be updated by pushing from repo1 or pull from repo2.

 

However, whether it is push or pull, only the data warehouse is updated without updating the working directory.

 

It is important to remember this. Otherwise, you may often wonder why it is not as expected. after push or pull, the data warehouse of repo2 is inconsistent with the working directory. In this case, you need to execute the Hg update command under the repo2 directory to update the working directory to be consistent with the data warehouse.

 

When using a remote server as a host like SVN, you must execute update after each pull operation. The two operations obviously cause inconvenience. In tortoisehg, you have integrated such a command. Right-click tortoisehg and choose syncronize to open the synchronization window,

Click "post pull" and select "Update" in the pop-up window. The update will be executed immediately after each pull operation.

You can also write a batch file in the root directory of the project, which includes the following two lines:

Hg pull

Hg update

In the future, when you need to obtain updates, double-click the batch. I think the command is convenient ......

 

The above briefly lists the basic usage of mercurial. For operations such as querying historical modifications, the menu of tortoisehg is very simple, and there is no difference with SVN. Just click here and have a look.

 

Mercurial comes with a simple serve command for transferring data between two computers, for example, executing the command Hg server in the D: \ repo1 directory, starts a service process listening on port 8000 by default. This command returns a URL address, another computer can copy the local repo1 repository in the form of Hg clone <URL> Local-path, but this serve command is obviously only a very simple temporary path, if you want to configure a central repository of servers, you should not just use the serve command, but use IIS or other Web servers, the next article describes how to set up a mercurial web server on IIS. See distributed version control system mercurial (2): Web Server SETUP