So I was learning mercurial.

There was one point where in the tutorial [link], the author talked about creating a second repository as a developer repository apart from the stable repository. As obvious from the name he planned to to use this for development and push to the stable versions after tagging them.

I wondered why? When we can simply create a branch, why on earth a second repo?

The two immediate problem that striked me were:

It would take up more space as we keep cloning the same data again and again

How does it compare to branching, in branching we have all versions in the same location, at least that’s what i have seen in many organisations’ repositories on GitHub like OpenCV

While I haven’t found the answer to the second one, the answer to the first one is rather interesting.

Mercurial uses hard links

Say we have a repo called ` project-stable-1.0 `, now to develop the next version we simply clone it say ` project-dev-2.0 `.

Now what happens is that project ` project-dev-2.0 ` has all information as project-stable-1.0 all files, everything, but..but.. the information is NOT copied.

That’s what hard links are.

So basically files can have multiple names, it goes against the earlier intuition but yes, multiple names of the same file.

So the python’s executable is stored in hard disk at some block, it can have multiple names at different locations, but the information is stored at one place only:

Both the

While Soft Links or Symbolic links are links between files :

Lets experiment a bit and see!

Currently we are in a directory inside ` /home/Documents/blog/ `

ls inside the blog directory

In linux the ‘ ln ’ command by-default creates a hard link. Let’s use it to create one for a.cpp.

`$ ln a.cpp hardlink_to_a`

So we have a new file there !

Now let’s create a softlink to a.cpp. | Just pass a -s flag to the ` ln ` command

`$ ln -s a.cpp softlink_to_a`

You see that beautiful color and arrow in the last line, also notice the l in lrwxrwxrwx in the last line, that shows a symlink is there!

But sadly nothing is there that shows a.cpp and hardlink_to_a are related 😕

It’s time wear the Sherlock Hat 🔬 😎 [no hat sticker, 😒]

A stat command on a.cpp and hardlink_to_a reveals something !

Notice the inode numbers of a.cpp and hardlink_to_a , they are same !! It even shows 2 in the Links entry ! While softlink_to_a has a different inode.

What are i-nodes ? 👀

Inodes are indexes. Every file has a data structure (record) on the filesystem, known as an inode that stores information about the file. It’s basically a primary key in the database.

In this case, having same inode numbers which means they are the same entry in the filesystem database and have different names.

So in a soft-link there is another inode which points to this inode :

Hard links are different :

As you can see both the ‘names’ point to the same inode, and inodes are entry on the filesystem, you can not create hard link outside a particular file system because that content won’t exist in a different file system.

Behaviour on changes to source

When you move or delete the source of these links, they behave differently! Symbolic links merely contain a string which is the pathname of it’s target , so it is not updated, hence the symbolic link has no usage now. Hard links on the other hand always refer to the source, even if moved or removed. So no effect on it 😎

For example, if we remove a.cpp. The softlink_to_a refers to a null file ‘ a.cpp ’ which no longer exists, but new file name a.cpp will be created if you edit te softlink_to_a. But the hard link is intact!

Notice the red highlight of the softlink

But we can still use the hardlink_to_a | $ nano hardlink_to_a

Drawback of Hard Links

Your linux installation may have multiple filesystems, but the most significant drawback is that hard links cannot be created to link a file from one file system to another file on another file system. Each file system maintains its own information regarding the internal structure of the system and the individual files on the system. Hard links only know this system-specific information, which make hard links unable to span file systems. Soft links, on the other hand, know the name of the file,just a string, which is more general, and thus are able to span file systems.[1]

For a concrete analogy, suppose that our friend Sayan Sinha is a student at both IIT-KGP and Stanford University. Both universities assign him a roll number. If he tries to use his IIT-KGP student number at Stanford, he will not meet with any success. He will also fail if he tries to use his Stanford student number at IIT. But if he uses his legal name, Sayan Sinha, he will probably be successful 🎉. The roll numbers are university-specific (like hard links), while his legal name spans both of the university (like soft links).[1]

Here is an example that demonstrates a situation where a hard link cannot be used and a symbolic link is needed. Suppose that we try to create a hard link from the current working directory to the a.cpp

An example to demonstrate this :

The ln command fails because a.cpp is stored on a different file system. If we want to create a link to it, we will have to use a symbolic link:

Differences :

Symbolic Links :

Easy to understand : especially if you have used windows before

Works for both files and directories

Works across filesystems

Hard Links :

Hard to recognize

Only works for files

Not possible across filesystems

Better performance

So the use of hard link in hg clone makes the operation fast and cheap.