Distributed version control system

Distributed version control system

--mercurial

Introduction of distributed version control system

(1) CVCs and Dvcs

Centralized version control systems centralized versioning system

Distributed version control Systems distributed versioning system

Distributed version Control (DVCS) is a way of managing file versions that do not require a central server, but it can also use a hub server. Changes can be merged into the system of any other user in DVCS, so a very flexible workflow can be implemented. The two main advantages of DVCS are that it is more flexible than centralized versioning because it supports a variety of workflows in addition to traditional (centralized) workflows; it is much faster than a centralized server because most operations are done locally on the client and do not require network operations.

There are three key differences between DVCS and centralized version control systems. The first difference is that DVCS is supported offline through local submissions, which is determined by the way DVCS operates. This is completely different from centralized versioning, which requires that all operations be performed through a connection to a hub server. This flexibility allows developers to work on airplanes as easily as they do in an office, and can submit them again and again.

The second difference is that DVCS is more flexible than a centralized system because the DVCS supports many different types of workflows, from traditional centralized workflows to pure special workflows, to a combination of special workflows and centralized workflows. This flexibility allows development through e-mail, peer-to-peer networking, and any way the development team likes.

The third difference is that DVCS is much faster than a centralized version control system because most operations are performed on the client, very quickly. In addition, the speed is faster when a push operation is required (to communicate with another node) because the full metadata is available on the two client machines. The speed difference is significant, and DVCS is about 3-10 times faster than Subversion, depending on whether a local or networked repository is used.

(2) Distributed version control workflow

①partner workflows. According to the Partner workflow, a developer starts a project and then branches it. Then merge the changes back and forth between the branches that the different developers work on.

② uses a centralized server through local submission. In this workflow, developers work in much the same way as they do with centralized Subversion repositories, but they commit locally and then push the final changes to a centralized server. This workflow has many variants, including the use of Partner workflows. Importantly, there are many ways to work, and by using DVCS, you have the flexibility to choose the work style that works best for you.

Second, Mercurial-distributed version control system

(1) Mercurial Introduction

Mercurial is a lightweight distributed version control system, implemented in Python language, easy to learn and use, and strong scalability. It is an open source project based on the GNU general public License (GPL) license. Compared to the traditional centralized subversion versioning, it has the following advantages:

Easier to manage. The traditional version control system uses the centralized repository, some and repository related management can only be carried out by the administrator alone. Because of the distributed model, there is no such trouble in Mercurial, each user manages his own repository, the administrator only needs to coordinate these repository.

More robust systems. Distributed systems are more robust than centralized single server systems, and a single server system cannot run without problems with the server, and distributed systems are not usually affected by one or two nodes.

Less dependent on the network. Since synchronization can take place at any time, Mercurial can even be managed offline, only when there is a network connection.

(2) Repository Warehouse

The repository in the version control system, like a warehouse, is used to store managed data files that contain different versions of the data files. In the traditional version control system, such repository are centralized. In addition to such a centralized repository, each user will have a copy of their working version. Users synchronize their own copies and centralized repository by command.

The repository in the Distributed version control system is a peer-to-peer network approach. In traditional centralized management, there is only one copy of the Repository, the others are only working copies, and no additional versions are included. Distributed management, each user is a real repository, which stores a different version of information and maintenance of a repository necessary auxiliary metadata. In such a peer-to-peer mode of work, the user completes the synchronization by exchanging the changeset described below.

Some of the advantages of doing so are that the degree of parallelism in the work will be greatly improved. Each user can carry such a repository, from where he can switch the current working copy to any version stored in repository. This version can be a previous version of the work, now need to merge into some other people's opinion, can also be a user-owned version, is currently doing a lot of forward-looking work, has not been able to sync to other users. It is also because of this pattern that each user can arbitrarily swap one version of their own repository to other users without having to roll back the version they are working on. The illustration below is a demonstration of such a flexible working mode.

(3) elements in the Mercurial

①revision

Each change in a system that uses Mercurial is isolated in its own repository, avoiding the mixing of unrelated code, and facilitating the testing of each part of the work, each of which is called a revision. There is usually a repository that all users can access to save the "major" version of the project, work repository is where users do things themselves, implement new features, modify vulnerabilities, refactor, experiment, and so on, and when the change is complete, you can push to the shared In Repository, a revision is completed.

②changeset

The change of one or more files is assembled together to form a logical unit called changeset. Each changeset is described by two parts, a version number and a changeset identity, for example:

The number in front of the colon represents the version number, which is used to identify the local changeset. This version number only makes sense in the user's local repository. The long hexadecimal string following the colon is the changeset identity, which is the globally unique identifier that determines the changeset, and is the same in all repository that contain this changese. Discussion of changeset between multiple users, typically using this changeset identifier, rather than the version number mentioned above, because it is entirely possible that the same changeset version number is different for each user's repository.

③head

The head represents the newest revision for each branch in the repository, which is commonly used when merging several branches.

④tip

Tip is an alias for the latest version number of a changeset. You can use Tip to replace the latest changeset version number anywhere in the command using the version number. Tip is different in each repository, and there is only one tip in a repository.

⑤log

The log command records every occurrence in the repository from close to far in chronological order. You can specify the-V Diagnostic output option to get more detailed historical information, or specify the-debug option to get all the details in historical information.

Iii. installation and use of mercurial under Windows and Linux

(1) Installation and use of mercurial under Windows

① Download Tortoisehg-0.7.6-hg-1.2.1.exe executable program, directly installed, you can also compile the installation from the source code, see

Http://www.selenic.com/mercurial/wiki/index.cgi/WindowsInstall

② the project owner to create an original version and set it up

③ Create a local repository

④ create a file in the warehouse after the local repository (empty folder in the original warehouse)

⑤ add files to local repository

⑥ to local repository after adding files

After submission, the file in the local repository is shown below:

⑦ Create an accurate clone version and place it in a location that other team members can access to share with other team members

⑧ other team members to access public sites for updates

Use of ⑨pull and push, add an empty zip file in Dvcs host, add an empty HTML file and BMP file in Dvcs client1

Merge with your local repository library

We get blank.zip from the pull update from the DCVS host repository. Here's how to use the push

Note that the above two parameters are set

⑩ Other Features

(2) mercurial installed under Linux (VMware Centos5.3,vmware in hostonly mode and host communication)

① download mercurial-1.2.1.tar.gz source download Address: http://me