Version control or source control is the management of changes to documents, programs, and other information stored as computer files. It is most commonly used in software develoment, where a team of people may change the same files. Changes are usually identified by a number or letter code, termed the “revision number”, “revision level”, or simply “revision”. So it is also known as revision control.
Version control systems (VCSs – singular VCS) most commonly run as stand-alone applications, but revision control is also embedded in various types of software such as word processor (e.g., Microsoft Word, Openoffice.org Writer, K Word, Pages, etc.), spreadsheets (e.g., Microsoft Excel, Openoffice.org Calc, K Spread, Numbers, etc.), and in various content management systems (e.g.,joomla, WordPress).
Distributed revision control
Distributed revision control (DRCS) takes a peer-to-peer approach, as opposed to the client-server approach of centralized systems. Rather than a single, central repository on which clients synchronize, each peer’s working copy of the codebase is a bona-fide repository. Distributed revision control conducts synchronization by exchanging patches (change-sets) from peer to peer. This results in some important differences from a centralized system:
- No canonical, reference copy of the codebase exists by default; only working copies.
- Common operations (such as commits, viewing history, and reverting changes) are fast, because there is no need to communicate with a central server.
Rather, communication is only necessary when pushing or pulling changes to or from other peers.
Mercurial is a modern, open source, distributed version control system, and a compelling upgrade from older systems like Subversion. Developers use it to manage source code.
In Mercurial every developer has a copy of the entire repository on their hard drive. It’s actually safer. And anyway, almost every Mercurial team uses a central repository, too, which you can back up compulsively, and you can build a three-ringed security zone complete with layers of Cylons, Stormtroopers, and adorable labradoodles.
Branching causes problems in Subversion because Subversion doesn’t store enough information to make merging work. In Mercurial, merging is painless and easy, and so branching is commonplace and harmlessn Mercurial, every developer has their own repository.So you can commit your code to your private repository, and get all the benefit of version control, whenever you like. Every time you reach a logical point where your code is a little bit better, you can commit it.Once it’s solid, and you’re willing to let other people use your new code, you push your changes from your repository to a central repository that everyone else pulls from, and they finally see your code. When it’s ready.
Mercurial separates the act of committing new code from the act of inflicting it on everybody else.
And that means that you can commit (hg com) without anyone else getting your changes. When you’ve got a bunch of changes that you like that are stable and all is well, you push them (hg push) to the main repository.
Subversion likes to think about revisions. A revision is what the entire file system looked like at some particular point in time.In Mercurial, you think about changesets. A changeset is a concise list of the changes between one revision and the next revision.
“Mercurial thinks in terms of “changesets” instead of “revisions” it can merge code much better than Subversion.”
Subversion is basically revision control for files, but in Mercurial, revision control always applies to an entire directory—including all subdirectories.
Actually Mercurial serves two important purposes:
- It keeps track of every old version of every file
- It can merge different versions of your code, so that teammates can work independently on the code and then merge their changes
The command for Mercurial is hg:
basic commands: use "hg help" for the full list of commands or "hg -v" for details
hg init – creates a repository
hg add – schedules files to be added to the repository. They won’t actually be added until you commit
hg commit – saves the current state of all files to the repository
hg log – shows the history of changes committed to the repository
hg revert – revert changed files back to committed version
hg status – shows a list of changed files
hg diff – shows what changed in a file
hg remove – schedules files to be removed from the repository. They won’t actually be removed until you commit.
hg cat – shows any revision of any file.
hg update – update the working directory to a particular revision
hg serve – runs a web server to make the current repository accessible over the Internet
hg clone – make a complete copy of an entire repository
hg push – push new changes from this repository into another
hg outgoing – list changes in current repository waiting to be pushed
hg merge – merge two heads
hg parent – show the changeset that’s in the working directory