Repo corrupted again, no idea why
Mads Kiilerich
mads at kiilerich.com
Sun Oct 3 23:22:55 UTC 2010
Luis Navarro wrote, On 10/03/2010 11:56 PM:
> Thanks again for everyone who responded with very useful information.
> Special thanks to Adrian who started the new Wiki page on hard linked
> clones....I think that will be very helpful for people who aren't
> familiar with this issue.
>
> I've got a few follow-up questions:
>
> 1) Is "hg clone" (without --pull option) the *only* Mercurial / THG
> operation that creates hard links?
Yes.
> 2) Regarding the "breaking hard link" method that Mercurial is
> supposed to use in the normal case (no Windows shares, hard links in
> use), this method is only used to break the hard links for files that
> are being updated, right? In other words, if my repo has 100 hard
> links and 3 existing files are modified and committed, Mercurial's
> only going to "break the hard links" for those 3 files, right?
Yes.
> 3) Regarding the recent Mercurial fix to address the Windows API
> deficiency, does this workaround only come into play for clone
> operations? Or does it come into play for commits, pushes, etc as well?
The recent fix has to work with repos that already has been cloned with
hardlinks, so it affects all operations that modifies the repository.
For example, instead of appending a few bytes to a 10 MB file it will
have to read the 10 MB and write the 10+n MB back. For every file it
modifies.
> 4) I was able to obtain hlscan.exe from the Windows Server 2003
> Resource Kit Tools download and determined that all of the repos (dev
> and staging) on "Server A" do have hard links. The production repo on
> "Server B" does not. As a result, I believe the following will fix my
> situation going forward:
>
> Step 1 - Upgrade all of our Mercurial and THG installs to the latest
> versions
> Step 2 - Recreate all repos from the production repo using "hg clone
> --pull"
>
> Is this correct?
Either of them will do.
> 5) Regarding #4, if I want to employ hard links for efficiency
> reasons, I could drop the "--pull" option and still be safe *if*
> everyone who uses these repos (even over shares) uses the new fixed
> versions of Mercurial and/or THG, right? (More specifically, I'd have
> to create the first Server A repo from production and then the rest of
> the Server A repos from that first one I just created.)
Well, yes, but ...
Yes, hardlinks allows fast clones and saves some diskspace. It can thus
give some efficiency.
But because there isn't any (feasible) way to detect hardlinks over
"windows shares" we must assume that everything is hardlinked and can
thus never append to files but has to "rewrite" the whole file. That
makes Mercurial over windows shares quite inefficient performancewise.
Talking about hardlinks being efficient in the context of windows
network drives is thus a bit misleading.
It could perhaps be convenient if we had a "this repo do not contain any
hardlinks" flag that could make network access faster and prevent
hardlinked clones. A reliable implementation would however have to be
non-backward-compatible to prevent old unaware Mercurials from creating
hardlinks.
The solution: Use a proper Mercurial server for shared repositories.
Windows shares isn't suitable for serious use.
/Mads
More information about the Mercurial
mailing list