Distributed version control (III)

This article introduces mercurial.

Because this is the SCM that I use most now-it has been used by several programs in the last month-so it will be detailed.

I saw the introduction of mercurial in Yunfeng's blog. He introduced several common DRCs in his article. He personally recommended darcs, but I took a fancy to mercurial.

Mercurial has the advantage that it is powerful and extremely fast (compared with SVN, it seems to be faster than Bazaar). mercurial is also written in Python as the source code, but the release version is like an EXE compiled with py2exe and other tools. I don't know why the speed is so fast. The disadvantage is that the remote repository operation requires some Server installation and configuration work, which is not as convenient as bazaar.

For more information about how to use mercurial, see the two-page documentation. Although mercurial's operation commands are similar to bazaar, the design concept is more "distributed" than bazaar, which is significantly different from traditional SCM and may take some time to adapt.

It's easy to install. download the latest version of the installer here to install it.

However, to use remote repository over SSH in windows, some additional installation and configuration work is required. If you are not using Windows or have installed cygwin with SSH commands on Windows, you can skip the following section and directly go to the "Mercurial usage" section.

First download a putty tool program: plink.exe.

Find the mercurial. ini file in the installation directory of mercurial, open it in the editor, and add the following two lines to the [UI] section:

ssh = D:/tools/plink.exe -ssh -pw password
username = username<username@sitename.com>

The username item is very understandable, which is equivalent to the whoami command in bazaar. I don't know why mercurial does not use this command. Instead, the current user is marked by loginname @ hostname by default, probably, it thinks this is just a sign. It doesn't matter. Anyway, it has a powerful branch/Merge function.

SSH is the configuration item related to ssh. As described in the reference document, mercurial prompts you to enter the logon password when operating remote repository through SSH. However, I failed to test the password in windows, which may be a problem with plink. Therefore, when cloning from a remote repository to a local repository for the first time, you need to use the-PW option to enter the logon password here (you can remove this option after use-because different projects may use different remote repository, therefore, different users and passwords may be used, which can be configured for the project at that time. in hgrc, see the instructions below ).

Use of mercurial:

After necessary installation and configuration, you can start using it.

The mercurial command is Hg-that is, mercurial. But to be honest, I saw mercurial thinking of mercurial.

There are two scenarios for starting a project: one is that there is no new repository project; the other is to join an existing project-a common remote repository has been created.

In the first case, the process is roughly as follows:

1. Create a local repository. Run the following command in the working directory of the project:

hg init

A. Hg directory will be created.

2. Configure the project directory (optional ). There are two main items. One is configuration. hgignore, excluding files that do not need to be added to the management; the other is configuration. hgrc is mainly used to configure SSH (this option is only applicable when plink is used for SSH connection in Windows ):

The. hgignore file is placed in the root directory of the project. The content of the file is as follows:

syntax: glob

*.py[co]
*.swp
*~

The usage is clear at first glance and will not be explained.

The. hgrc file is placed in the. Hg directory. The content is as follows:

[paths]
default = ssh://username@remotehost//home/username/projname
default-push = ssh://username@remotehost//home/username/projname
[ui]
ssh = D:/tools/plink.exe -ssh -pw password

The default/default-push in the paths segment is the default URL for remote download and upload, so that you do not need to enter this URL each time for the pull/push operation. If SSH is not configured on standard port 22, you can add (: Port) to remotehost to specify the port number.

The configuration in the UI section is in the same format and meaning as mercurial. ini. To use plink to connect to SSH in Windows, you need to use the-PW option to configure the logon password so that the pull/push operation can work properly.

3. Check the project status. Command:

hg status

All valid project files without commit and their statuses are listed. If the project file is not modified after commit, no feedback is provided.

For example, after the initialization is complete, all project files will be listed (Files excluded by. hgignore will not be displayed), and there is? Indicates that these files have not been managed by version.

Check after the first add operation, then? The flag changes to the flag, indicating that it is a new file.

If a file has been modified after commit, the status check will list the modified files and add the m mark.

If a file is deleted or renamed after commit, the file will be added to the status check! Mark-the new file after the name is changed will be added as an unmanaged new file? Flag.

Need to delete from local repository! The remove command is required for the flag file. For details, refer to the instructions below.

4. Add the project file to the local repository. The command is simple:

hg add

In the project directory. all files other than excluded files in hgignore are added to the local repository (of course not including. hg directory, but will include. hgignore file itself ).

5. Submit the change to the local repository. Command:

Hg commit-M "Instructions for this submission"

6. Submit to remote repository. Here, we will only introduce the method of submitting via ssh. For the HTTP method, please refer to the relevant documentation.

First, you need to install mercurial on the server. If you are using a Linux server, refer to the release notes. The installation in Ubuntu is very simple and can be directly used:

sudo apt-get install mercurial

You can.

Create an empty repository in the project directory of the server (bazaar does not need such a step, it can be created remotely using SFTP directly in the empty directory ):

cd /home/username/projname
hg init

Finally, you can push repository on the client and run it in the project directory:

hg push ssh://username@remotehostname//home/username/projname

If the default-push of the paths segment in. hgrc is configured, you can directly use:

hg push

If the submission fails, check whether the plink PW option is correctly configured in. hgrc and/or Mercurial. ini, or whether the ssh port number is correct. If the configuration still fails, you can use the debug option to view the error details:

hg push --debug

Let's look at the second case, that is, the remote public repository already exists.

1. Create a local copy first:

hg clone ssh://username@remotehostname//home/username/projname

Note: In Windows + plink, you must first. configure the PW option of plink in ini, otherwise it will not work properly-at this time there is no. hgrc can be configured, so only mercurial can be used. INI global configuration.

After normal execution, a subdirectory of projname will be created under the current directory, which contains all the content of the local repository (. Hg directory) and working directory.

2. You usually need to configure. hgrc (optional), but. hgignore will be cloned together and generally no longer need to configure it.

3. The status/Add/commit/push commands are the same as those in the first case.

Now let's take a look at some other operations required in both cases:

1. delete an object:

hg remove path/filename

The deleted file will be marked as R in the result of the status command. You can use the-I option to delete multiple objects with wildcards:

hg remove -I path/wildcard .

2. obtain updates added by others from remote Repository:

hg pull ssh://username@remotehostname//home/username/projname

Similarly, if. hgrc is configured, you can directly use it without entering a URL:

hg pull

Obtain updates. However, this operation only updates the local repository. You also need to use:

hg update

To update files in the working directory.

If a change conflict occurs, this operation will automatically perform merge. For parts that cannot be automatically merge, the default editor (which can be configured in mercurial. INI) will pop up and require manual processing. After the processing is completed, the local repository is automatically merged.

3. Supplement to push:

When pushing a remote repository, if someone else's push content exists, this push will automatically generate a branch, you need to perform a pull Operation to download all branches to the local repository for merge.

4. In addition to checking the working directory status, there are also several commands used to check the local repository status:

hg head
hg heads
hg log

The head command displays the submission information of the latest working branch version in the current local repository. The heads command displays the submission information of the latest version of all unmerged branches in the current local repository. The log command displays the submitted history.

Mercurial also has a strong change packaging and unpacking function, that is, a developer can package the change records in his local repository to others. After other developers get this change package, you can decompress the package to your own repository so that you can connect to the public remote repository. This "distributed" is too thorough.

For more information about mercurial, see here.

(To be continued)