Extensions are written in Python, so hone your scripting skills. Several extensions are available from the project, and you always can go ahead and write your own. One of Mercurial's strengths is its use of extensions. Changes also can be pushed to another repository. User two would need to do the same thing (pull and merge) in order to synchronize the repositories. User one then needs to merge these two branches together in order to incorporate all the changes since the last synchronization of repositories. This creates two branches in user one's repository: one branch for user one's changes and one branch for user two's changes. User one then pulls in any changes from user two's repository. So, what happens when two users are doing parallel development? Assuming they are starting with equal repositories, any committed changes by user one creates a new branch, and any committed changes by user two also creates a new branch. Right-clicking a file and pulling up the properties gives you lots of Mercurial information. For this reason, each revision also gets a 40-digit hexadecimal globally unique ID.įigure 2. But, remember that each working directory gets its own copy of the store, so these revision numbers may not actually match up. Each changeset gets a sequential number, called the revision number. When you commit a series of file changes, a single changeset is created, encapsulating these changes. This means that Mercurial has a distributed system, much like Git. Every working directory is paired with its own copy of the store. The store contains the history of the repository. A Mercurial repository consists of a working directory, which is paired with a store. These work flows are great starting points for you to create your own.įirst, let's look at what makes up Mercurial. Using those, you can see how you could use Mercurial as a solo developer or as one of a group of developers, or how to work with a central repository like CVS. Several tutorials are available, and they even include a series of work flows that cover how end users can use Mercurial for their development projects. The main Mercurial site contains lots of documentation for end users and developers alike. Hopefully, after reading this article, you'll have enough information to make a rational choice as to what is best for you. Mercurial provides some of the features of systems like Git, and some of the features of systems like CVS or Subversion. This article describes another option to add to the mix. Git may be the perfect fit for some people, and RCS may fit someone else better. There is no one perfect system to rule them all. They are all different and fit people and their work habits differently. I think version control systems are like editors. In case you didn't notice it, my tongue was firmly in my cheek in that last paragraph. I would like to challenge that assumption and declare to the world that the real perfect version control system is here, and its name is Mercurial. A short while ago, an article appeared in Linux Journal implying Git was the be-all and end-all of source code revision control systems (“Git-Revision Control Perfected” by Henry Van Styn, August 2011).
0 Comments
Leave a Reply. |