# HG changeset patch # User wenzelm # Date 1355752294 -3600 # Node ID 325bf9073c5910d819704fe5c78fec4a34eb883a # Parent ae1da46022d19cf52bb87bcca5dcd27c9ec4a33c more hints on technical issues due to shared-disk access of central Mercurial repository; diff -r ae1da46022d1 -r 325bf9073c59 Admin/Mercurial/Central/README --- a/Admin/Mercurial/Central/README Mon Dec 17 14:07:34 2012 +0100 +++ b/Admin/Mercurial/Central/README Mon Dec 17 14:51:34 2012 +0100 @@ -13,7 +13,9 @@ fncache * See http://mercurial.selenic.com/wiki/MultipleCommitters for old-fashioned - CVS-like multiple committers configuration, "The filesystem method": + CVS-like multiple committers configuration, "The filesystem method". + + A fresh multi-user clone is initialized like this: hg --config format.dotencode=0 init isabelle-clone cd isabelle-clone @@ -25,3 +27,26 @@ Now isabelle-clone is ready for push of repository data (without making a working directory). +* Addressing technical issues: according to + http://mercurial.selenic.com/wiki/PublishingRepositories our shared disk + configuration (after regular ssh login) is characterized as follows: + + Advantages: can use existing setup + + Disadvantages: generally restricted to intranets, not generally + recommended due to general issues with network filesystem reliability + + Due to NFS instabilities of unknown origin at TUM, drop-outs have + happened before. The following measures of last resort can be applied: + + (a) "hg verify" to find offending changesets + "hg strip REV" to remove parts of the public history by vivisection + + (b) fresh clone from known-good source as explained above + + Note that any such non-monotonic changes on the central push area work + under the assumption of sequential single-user mode!! + + See also http://mercurial.selenic.com/wiki/RepositoryCorruption for + further background information. +