Cygwin and Win32 native support

Matt Mackall mpm at selenic.com
Mon Mar 10 19:12:55 CDT 2008


On Mon, 2008-03-10 at 22:54 +0100, Patrick Mézard wrote:
> Guido Ostkamp a écrit :
> > 
> > On Mon, 10 Mar 2008, Patrick Mézard wrote:
> >>> On Mon, 2008-03-10 at 20:36 +0100, Guido Ostkamp wrote:
> >>>> So I tried Mercurial under Cygwin on the PC to clone
> >>>>
> >>>>    ssh://anon@hg.opensolaris.org/hg/onnv/onnv-gate
> >>>>
> >>>> over a socks 4 proxy using special ~/.ssh/config setting, but it got
> >>>> stuck after some ~17800 files. From at home I know there are much
> >>>> more. I retried this several times, but it always stops after
> >>>> reaching that number of files.
> >>
> >> Sounds like http://www.selenic.com/mercurial/bts/issue793
> > 
> > yes, I think that's it. It is exactly the same OpenSolaris repo, only
> > difference being that you clone over http while I had to use ssh.
> > 
> > In the bug report, someone mentioned the problem occurs when applying
> > file changes.
> > 
> > Do you think using the '-U' option ("do not update the new working
> > directory") for cloning would work?
> 
> No, the problem is the store itself cannot be created on Windows, for there is an "aux" directory.
> 
> >> From the error report it looks like analysis is finished but no decision 
> > has been taken on how to solve it. I consider this bug a serious show
> > stopper which should be fixed before Mercurial 1.0 as it might require
> > incompatible repo format changes, if I understand the bug report correctly.
> 
> I don't like the current solution because it fixes a specific issue
> with a specific hack. Unfortunately, there is no real abstraction at
> store level which makes this kind of hack really expensive in term of
> compatibility. Another crufty filesystem would trigger another issue.
> I cannot really think of a simple workaround for this, but maybe
> people experienced with the previous store format updates have better
> ideas. I probably don't understand the whole trade-off with file to
> store direct mapping, but given the other issues related to file name
> lengths it might be worth breaking it more thoroughly.

The file mapping issue is performance.

The first versions of Mercurial stored file paths by hash. This was fine
for small repos, but as soon as things grow larger than cache, things
get painful very quickly. And for a version control system, cold cache
is the usual case.

Hashed storage means that if you've got files layed out sequentially on
disk in your working directory, they're in random order in the store
(and vice versa)! With the former, you seek like crazy (and take 10x
longer) at checkout. With the latter, you scatter the checked-out files
all over the disk. And if you tar or copy your tree, you probably make
things even worse.

Instead Mercurial tries to arrange things so that your operating system
and your disk actually have a chance to optimize things. It always reads
and writes files in the store and in the working directory in
alphabetical order. This gives your system a chance to a) do readahead
and b) put files that are next to each other in the tree next to each
other on disk. And if you tar, copy, or clone your tree, you've probably
just defragged it.

So what should we do here? Probably we should bludgeon Windows into
creating the file anyway. The MS knowledgebase is full of articles on
how to delete such files once they're created so surely there's a way to
create them.

-- 
Mathematics is the supreme nostalgia of our time.



More information about the Mercurial mailing list