Introduction to mercurial

ArticleDirectory

• Overview

Overview

• Mercurial enables Unified Version Management for remote development. For example, some people in a project cannot use the Internet for internal development in the bank, while others are developed in the company, these two parties need a unified version management tool, which can be used by mercurial at this time.
• Mercurial has the same command as subversion, so the learning curve is not steep and can be used quickly. Commands such as ADD, commit, branch, and tag are similar operations. Mercurial also manages a global version number, and each version number has a unique ID identification. The version number is only a sequence number. The same version number of different version libraries does not have a comparative meaning, if the version ID is the same, the version is the same.
• Mercurial provides better support for Linux, windows, and Mac platforms. On the Windows platform, there are command-based mercurial.exe and graphic interface-based tortoisehg.
• The biggest difference between DVCs and centralized version management is that each machine has a version library, and a version library is like a SVN branch. So how to use branch and perform reasonable merge, version merge with other people also becomes very important, otherwise it will form a very bad heads, it will become chaotic.
• Mercurial exports Changeset to a file, which can be easily sent to another project team member by email attachment, and then imported to achieve version synchronization.
• Google Code has selected mercurial among the two most popular DVCs, but git has some advantages, such as version library storage and multiple parents for merge convenience.

Basic usage

Most of the following statements are in the command line format. The version is 1.2.11.

• Because the local database is the version Library server and the version library client, you must first distinguish the version library and working directory concepts. The version inventory contains all versions, the working directory is only a specific version. This concept is consistent with that of SVN, except that the SVN version library is not local, but on a server in the set.
• Hg init Create a new repository. The version library files are placed under A. Hg folder.
• Hg add Add unversionized files
• Hg commit Submit the modification and use-m to enter comments, which is the same as SVN.
• Hg tip Check the latest version of the current version library. Note: it is not the latest version of the current working directory. Tip indicates the latest version of the version library.
• Hg parents View the latest version of the current working directory. If this version has multiple parents, it is displayed. If it does not, it is not displayed. Parent refers to the previous version of a specific version. If a specific version comes from two versions of merge, multiple parents will appear. Mercurial does not support more than two parents. That is to say, only two versions can be merged. Merging three versions requires two operations, merging four versions requires three operations, and so on, if you need to merge eight versions, you need to merge seven times...
• Hg clone Clone a version library to your local machine. When the project starts, we recommend that you clone the init project from your computer instead of init.
• Hg pull Update version from another version library to local
• Hg push Update the local version library to other version libraries. You must activate the SSH service for other version libraries. cygwin is required for Windows to start SSH, and OpenSSH is used for Linux. When connecting to the SSH server on a Windows client, you must configure the UI segment of mercurial. ini as follows:

  [UI]
  SSH ="C: \ Program Files \ tortoisehg \ tortoiseplink.exe"
  
  
  

  Putty.exe cannot be used with Hg.
  Tortoiseplink.exe adds a "/" to the path after SSH: // XX/to indicate the root path, as shown below:
  SSH: // 192.168.107.129 // home/Arthur/Hg/Hello

• Hg incoming Compare the local version library with other version libraries to see which changesets can be pull in other version libraries.
• Hg outgoing Compare the local version library with other version libraries to see which changesets can be pushed to other version libraries.
• Hg update Update the working directory. The default parameter is tip. It can also be the version number, tag name, and branch name. Switch branch/tag in SVN using this command
• Hg tag Create a permanent version number, and store the tag in the. hgtags file. The file also needs to be versioned.
• Hg Branch Displays the current branch, or creates a new branch. The default branch name is default.
• Hg diff Differences between versions
• Hg merge Merge the version to the current working directory. If Hg merge is prompted after Hg pull and Hg update, merge is performed based on the latest version, the modifications made after merge need to generate a new version number through commit.
  • merge branch: Hg merge branchname, first confirm what HG branch is before executing this command.
    when a branch's historical mission is completed, you need to decide whether to open a branch based on this branch or in a previous version. default is the default branch name when no branch is created.
    if you want to continue working under the default branch, you need to first Hg update default, and then consider which versions need to be merged into the default, and then you can continue working under the default.
    when multiple branchs need to be merged to default, branchs must be merged one by one, such:

     Hg merge Foo 
     Hg merge bar 
     Hg ci-M " merge Foo and bar to  default  
     " 
     
     

  • in windows, if beyond compare is installed, it is automatically called.
    three windows are displayed: local files, base files (the last version before the branches are separated), and other files (external files ). This merge mode is the same as SVN.
    after merge completes, Hg Ci is required to submit the modification. At this time, we can see that there are two parents in the tip information, indicating that they are from two versions of merge.
    beyond compare has three basic options for conflict: take left, take center, and take right, which correspond to the content of the above three files respectively. Several other options are also easy to understand. In case of a conflict, you may need to manually enter the content.
    In addition, if Program is not installed, the text editor is enabled to access the files to be merged. It is very error-prone and tedious to do these tasks manually. It is best to exit the editor and use the Hg rollback command to clear the changes brought about by ["pull"], then install the merge program, and then run it again.
• Hg heads Head refers to the Changeset without a son chaneset, that is, the leaf node of the version tree. Multiple leaf nodes can be merged into one leaf, branch Heads refers to the Changeset that has been assigned a tag but has no son Changeset. Use Hg heads to display all heads in the current database. If multiple heads exist, multiple parallel development paths are available. In this case, you need to consider whether to merge them.
• Hg serve-n "hellohg"-P 80 Run the network service. You can then download this version library through Hg pull http: // localhost/hellohg. This is a temporary and convenient way to provide the pull version library service.
• Hg export Export Changeset. Tip is exported by default. You need to use redirection to export the data to a file. After that, the file can be sent through an email attachment to synchronize versions without network connections.
• Hg Import Import Changeset