May 12, 2012 at 10:32Hard links when cloning a repository in mercurial
When cloning a repository using the command
Hard links are supported by Linux and Windows NTFS file systems. For file systems that do not support hard links (for example, Windows FAT), as well as when cloning via http / https or ssh from a remote server, mercurial completely copies all files.
In order for mercurial to create an independent repository clone, you can manually specify the --pull parameter:
When committing or pushing changes to the repository, mercurial checks the number of hard links for each file in the .hg folder. If there are two or more links, then before writing the hard link for this file “breaks” (the XXX file with the hard link is copied to a temporary file, the XXX file is deleted, the temporary file is renamed to XXX).
On computers running Windows, when you receive the number of hard links to files located on shared resources, 1 is always returned, even if there are actually more.
This means that mercurial when committing to a repository located on shared resources can break other repositories whose files are tightly connected to the files of your repository. Moreover, when committing, there will be no error message, because the repository to which the commit took place will be intact. You can check the repository with the command
It says here that starting with version 1.6.3, to prevent such situations, mercurial always commits hard links when committing if the repository is on a Windows share.
Now I have version 2.2.1, but when you commit to a repository for a shared resource, other repositories tied to it still break. The problem was solved only after all repositories were cloned with the --pull option.
There is some magic in this behavior by default, because of which you can grab some share of the headaches, which I successfully grabbed. Therefore, I decided to transfer this information here. I hope someone saves time and nerves.
Original: http://mercurial.selenic.com/wiki/HardlinkedClones
Recovering broken repositories:http://mercurial.selenic.com/wiki/RepositoryCorruption
hg clone A BHard links are supported by Linux and Windows NTFS file systems. For file systems that do not support hard links (for example, Windows FAT), as well as when cloning via http / https or ssh from a remote server, mercurial completely copies all files.
In order for mercurial to create an independent repository clone, you can manually specify the --pull parameter:
hg clone --pull A BWhen committing or pushing changes to the repository, mercurial checks the number of hard links for each file in the .hg folder. If there are two or more links, then before writing the hard link for this file “breaks” (the XXX file with the hard link is copied to a temporary file, the XXX file is deleted, the temporary file is renamed to XXX).
Cloning on Windows Shares
On computers running Windows, when you receive the number of hard links to files located on shared resources, 1 is always returned, even if there are actually more.
This means that mercurial when committing to a repository located on shared resources can break other repositories whose files are tightly connected to the files of your repository. Moreover, when committing, there will be no error message, because the repository to which the commit took place will be intact. You can check the repository with the command
hg verifyIt says here that starting with version 1.6.3, to prevent such situations, mercurial always commits hard links when committing if the repository is on a Windows share.
Now I have version 2.2.1, but when you commit to a repository for a shared resource, other repositories tied to it still break. The problem was solved only after all repositories were cloned with the --pull option.
There is some magic in this behavior by default, because of which you can grab some share of the headaches, which I successfully grabbed. Therefore, I decided to transfer this information here. I hope someone saves time and nerves.
Original: http://mercurial.selenic.com/wiki/HardlinkedClones
Recovering broken repositories:http://mercurial.selenic.com/wiki/RepositoryCorruption
