Repository on CIFS

[Martin Geisler]

Augie Fackler <raf at durin42.com> writes:

> On Nov 23, 2013, at 3:08 PM, Koen Vermeer <koen at vermeer.tv> wrote:
>
>> Hi,
>> 
>> I have set up a Linux server that we can use to access our
>> repositories. It runs the hgweb.wsgi script through nginx and uwsgi.
>> This seems to work fine when the repositories are stored locally on
>> the server.
>> 
>> However, I was trying to store them on a CIFS mount. I've only done
>> some quick tests, but I ran into a problem: It seems that when
>> folders need to be created, it fails. Repeating the same operation
>> (sometimes a few times) works. I was wondering if I'm just missing
>> some detail, or that this setup is not expected to work.
>> 
>> I was unable to find any suggestions on, for example, mount options
>> to use for such a setup. I'd be grateful for any help!
>
> Is there a particular infrastructural reason you're trying to use
> CIFS? Mercurial depends (intentionally) on some particular features of
> local filesystems, and using something like CIFS is generally a recipe
> for repository corruption.

Should you not qualify that statement a bit?

Something like "if you access a repository stored on a CIFS mount with
multiple Mercurial clients who all read and write directly to the
filesystem, then X might happen".

Put differently, do you know how the repository can be corrupted when
the clients access it over a network filesystem like CIFS?

In a setup with hgweb, I can easily imagine that all writes take place
through hgweb and that all hgweb processes run on the same box. The
kernel on that box ought to make sure that the hgweb processes see a
consistent filesystem -- someone please correct me if that's not true.

-- 
Martin Geisler

http://google.com/+MartinGeisler | http://careers.stackoverflow.com/mg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial/attachments/20131124/b1f6979e/attachment.pgp>