Mercurial (HG) basic operations

Introduction to mercurial

Mercurial is an excellent distributed version control system (dcvs). It has the advantages of high efficiency, cross-platform, scalable, easy to use, and open source. It is one of the most popular version control tools. Mercurial is often abbreviated as Hg because mercurial is short for mercurial. Before using mercurial, I used VSS (stopped updates), SVN, and Microsoft TFs. They are not distributed version control systems. In other words, when the source code server fails or the network is disconnected, you cannot submit your local modifications. This is also the biggest difference between the previous version control tool and mercurial. Git is also a tool similar to mercurial, but I personally do not like it because the support for Windows systems is not very user-friendly.

When I first came into contact with mercurial, due to the long-term use of SVN, I was used to relying on the central source code server. I also felt that mercurial operations were awkward and not very convenient. But after using it for a while in the project, I like it. Below we will release some mercurial-related information:

1. Mercurial Official Website: http://mercurial.selenic.com/
2. Mercurial client (tortoisehg): http://tortoisehg.bitbucket.org/
3. Visual Studio supports the use of mercurial plug-in visualhg: http://visualhg.codeplex.com/. if you are using Visual Studio 2010 or later, you can directly obtain this plug-in from the Extension Manager.
4. Mercurial official Chinese Tutorial: http://mercurial.selenic.com/wiki/ChineseTutorial
5. FreeCodeManaged Services: https://bitbucket.org/. free accounts can manage 5 Users and private projects in the public republic.

Install mercurial

Tortoisehg itself integrates mercurial's server functions. Therefore, we only need to obtain and install the latest tortoisehg to implement local file version control. Next, you need to download and install visualhg so that we can use mercurial in Visual Studio.

Tortoisehg is integrated in the resource manager. After the installation is complete, right-click the blank area on the desktop to view the menu items of tortoisehg. For details, see:

In Visual Studio, right-click the solution file or project file in solution manager and the following menu appears:

If you see the same result after the operation, it means that you have completed the local installation of mercurial. At this time, you can use it to control the version of local files. If you want, you can even set up a mercurial Version Control Server locally.

 

Basic mercurial operations

1. Create a version Library

Right-click any folder and you will see the following menu:

In the submenu of tortoisehg, select "create version library in the current location". A new session window is displayed:

Select "add special file". The Global ignore file of Hg is added here. Taking Visual Studio as an example, the global ignore rules are as follows:

 
# Ignore FileForVisual Studio 2008
 

 
# Use glob syntax
 

 
Syntax: Glob
 

 
# Ignore visual maxcompute 2008 files
 

*. OBJ
 

 
*. Exe
 

 
*. PDB
 

 
*. User
 

 
*. MSI
 

 
*. APS
 

 
*. PCH
 

 
*. Vspscc
 

 
* _ I. c
 

 
* _ P. c
 

 
*. NCB
 

 
*. Suo
 

 
*. TLB
 

 
*. Tlh
 

 
*. Bak
 

*. Cache
 

 
*. Ilk
 

 
*. Log
 

 
*. Lib
 

 
*. SBR
 

 
*. SCC
 

 
*. SWS
 

 
*. Pdsync
 

 
*. Pdsyncu
 

 
~ *. Doc
 

 
*. Orig
 

 
[Pp] ackages */
 

 
[BB]In*/
 

 
[DD] ebug */
 

[Ll] ogs/
 

 
Backup/
 

 
OBJ/
 

 
[RR] elasticsearch */
 

 
_ Resharper */
 

 
_ Upgradereport_files/
 

 
[TT] est [RR] esult *
 

 
[BB] uild [ll] og .*
 

 
*. [PP] ublish. xml
 

 
Upgradelog. xml
 

 
*. Csproj. User
 

 
*. NCB
 

 
*. Suo
 

Click "CREATE" to create the local version library. Now you can see the green check box of the familiar icon. Yes, it is the same as that of SVN.

2. Submit the change set to the local version library.

In the solution manager of Visual Studio, right-click the solution and you can see the following menu:

After selecting commit, you can see the submit session window:

We strongly recommend that you write submit logs with clear semantics and clear description of the change set. You can also right-click the solution folder to perform the same operations as described on the same page.

3. Use Bitbucket to manage the project source code

If the current project is a personal small project, the above operations can meet the needs. However, for projects with multiple participants in cooperative development, it is obviously not enough to submit only the change set locally. Without a stable private source code server, I currently (recommended) Use Bitbucket to host the project source code. The free version of The Bitbucket account can be managed by up to five members. For general development teams, I think this is enough. Let's talk about how to use Bitbucket to manage the project source code.

Register a Bitbucket account. After logging on to the console, you can see the following information on the control panel page:

 

On the left is the latest change information and event operator of the project you participated in, and on the right is the project you participated in or hosted. The closed lock indicates that the current project is a private project. Only the developer specified by the project owner can submit and modify the source code, which is only visible to team members; the development lock indicates a public project. The source code is visible to everyone. Anyone can view and download the source code. Click the green plus sign next to repositories to create a new version library. You can also use the import version library function next to it to synchronize the source code from other source code servers and create a version library. After creating a version library, you can see the following session interface:

Programming LanguageThe drop-down list contains almost all development language types. Although this has little impact on version control, we recommend that you select the correct language type. After the project is successfully created, the Project Management page is displayed. For details, see:

Each tab represents a functional module. I will not go into details here. I will only describe the overview and Management (Admin) functions that will be used in the current introduction. On the overview page, clone is followed by the synchronization URL of the current project. Right-click the blank area of the local folder and choose tortoisehg-> clone:

In the pop-up session window, fill in the clone address in the "Source" column, and click Clone to download the version Library to the local machine:

Open the cloned local version library. The directory structure is as follows:

The. Hg directory is the local mercurial version library.

4. Obtain the external change set

We have already described how to submit the change set to the local version library. When multiple developers work together, we also need to synchronize the local change set to the central server. Before synchronization, we need to obtain the external change set. The procedure is as follows:

In the Hg workbench (right-click the blank area on the desktop), select the project to be operated, and click the downward icon:

In the displayed session window, enter the account password in the Bitbucket Website:

After obtaining the information, you can see the following branch list:

If the form of the branch list is shown in, it indicates that after you synchronize the local change set to the server, other members of the team have already merged, in this case, you only need to select update from the right-click menu:

Otherwise, the external change set and local change set must be merged.

5. Merge Change sets

Merge two different branches. As shown in, select "merge with local database" from the menu ":

In the merge session window, cancel the "automatically resolve merge conflicts as much as possible" option (I personally feel that this automatic merge will not only do little, but will affect the accuracy of the merged files ):

After the merge starts, the number of conflicting files is automatically displayed. Select the resolved option in the window:

In the list of conflicting files listed, select the "Mercurial resolve" option:

In this case, the conflicted file will be moved to the "resolved conflicts" list, select a file, and click "3-way diff )":

We recommend the three-way merge tool (beyond compare). The merge interface is shown in the following figure:

On the merge page, the local version is on the left, the external version is on the right, and the merged text is on the bottom. Click the Green Arrow to merge the local version to the file. Click the purple arrow to merge the external changes to the file. The version selection depends on the project.

After merging, select the current local file and click Save on the right of the drop-down box:

 

Click Submit to submit the merged results to the local database:

6. Synchronize the merged version to the managed Server

Open the Hg workbench and select the push button on the shortcut menu bar (green arrow on the right ):

In the displayed push session window, select "yes" and enter the account password of the Bitbucket:

After synchronization starts, you can see the synchronization status in the log output window at the bottom:

The progress bar ends. The synchronization operation is completed: