On Thu, 29 Nov 2012, Lars Noschinski wrote:
So we still carry a lot of CVS baggage stemming from 1993, not just in
the low-level technological sense.
Nothing new, all known already. I usually ignore it to avoid the trouble
of thinking about more fundamental changes.
We could make up a rule "always go through host X" (X being one of the
macbroys/lxbroys) and hope it is the simultaneous access from multiple
hosts and not the fact that it is laying on a NFS which makes it
unreliable.
I've been thinking of this occasionally, but it does not work either,
because the "gateway" systems that are reachable for ssh from outside are
fluctuating a lot. It used to be just atbroy100 as canonical example some
years ago, then one had to shuffle macbroy20..29 to get some machine that
happens to be available, now one occasioanlly needs to take the lxlabbroy
into account. I edit my .hg/hgrc a lot these days.
On Wed, 28 Nov 2012, Makarius wrote:
On Wed, 28 Nov 2012, Gerwin Klein wrote:
This may be entirely unrelated, but I've just had to re-clone the afp hg
repository in my home directory at TUM because it made mercurial crash on
pull, and failed integrity checking.
The only other time I've ever had to do that in the past few years of using
mercurial was because of file corruption due to a broken hard disk (two
cases). If this happens frequently to us, something may be very wrong with
storage on the macbroy/lxbroy machines.
The reliability of NFS at TUM has indeed degraded a bit, maybe already more
than 5 years ago, but it is hard to pin down.
I now remember the difference from distant past. Until approx. 5-6 years
ago, the NFS server (first sunbroy60, then sunbroy1, then sunbroy2) was
accessible by ssh. Thus everybody was using that for his ssh login in the
cvs configuration, because it made things much faster with the local
harddisk access on the remote host. So neither the NFS problem nor the
client program confusion did exist.
Then the NFS server was made more "secure", so users could no longer
login. I also remember now that it was the point where cvs became
unbearably slow, and thus accelerated our move to state-of-the-art version
control, where central transactions only happen occasionally (pull, push)
and not for every single commit (which is hard to imagine now).
So if there is an easy solution to more robust access of some file system
served at TUM, I am for it. Anything beyond that should be a move away
from home-made servers to some professional hosting platform like
Bitbucket (not Sourceforge, not Google code). Note that we have already
several home-made services running that are only half-maintained, and we
cannot afford this for the main collection point of Isabelle changesets.
Makarius
_______________________________________________
isabelle-dev mailing list
isabelle-...@in.tum.de
https://mailmanbroy.informatik.tu-muenchen.de/mailman/listinfo/isabelle-dev
