[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

svnadmin verify reports a clean repository, but IDE complains anyway

From: Howard Bryden <hdbryden_at_emergency.qld.gov.au>
Date: Tue, 29 Jan 2008 08:39:05 +1000

Ulrich,

<Typically, I'd expect 'svnadmin recover' to help here. What puzzles me
is the
fact that you say it is a new repository from a new installation of SVN.
Firstly, that installation wouldn't have created a BDB repository but an
FSFS
one. So, if that repository is in fact much older, it might have been
created
with an older BDB version and 'svnadmin recover' is just the right thing
to
do >

It certainly is, it was created with a command of the form

svnadmin create --fs-type=bdb {path-to-repository}

<(You do have backups, right?).>

Absolutely :-)

<Secondly, I would check file permissions. If you created the repository
as
user X and then accessed it with user Y (e.g. Y = root) using the
file://
URL, you might have screwed up file permissions. Note that even reading
actually requires and uses write permissions on the repository!>

The repository was created as root and the svnserve daemon runs as root
so there should not be any issues there. In any case basic permissions
problems would, I expect, have created many more problems - and more
consistently - than what we've only just started to see on an
intermittent basis.

< Option d) sounds appealing, and I wonder why (if?) you chose DBD in
the first
place. However, I have never had any big problems with BDB backends,
even
across BDB upgrades, except that I couldn't use one created with
Linux/x86 on
a machine running Linux/PPC, but that is expected and easily worked
around.>

The developer actually specified BDB as their preference. I've
subsequently seen some adverse commentary about BDB and have suggested
they consider a migration to FSFS.

<One more thing: can you reproduce the problems via the commandline
instead of
the IDE? It would be much nicer if you could rule out that point of
failure.>

Funnily enough, after another occurrence of this error, I went to
svnadmin verify but this time it failed straight away. I then saw that
the svnserve daemon actually had two child processes, running the same
executable and reporting the same command line arguments. Believing
this was strange, I terminated all three process and restarted svnserve,
whereupon repository verification succeeded. Maybe this was at the
bottom of the mystery.

Thanks for your help, we'll see what happens further.

Howard Bryden,
UNIX Administrator,
Qld. Govt. Dept. of Emergency Services,
Tel. 07 3109 5087

------------------------------------------------------------------------
----------------------------------
Rocket J. Squirrel: "... we're going to have to think!"
Bullwinkle J. Moose: "There must be an easier way than that."

This correspondence is for the named persons only. It may contain confidential or privileged information or both. No confidentiality or privilege is waived or lost by any mis transmission. If you receive this correspondence in error please delete it from your system immediately and notify the sender. You must not disclose, copy or relay on any part of this correspondence, if you are not the intended recipient. Any opinions expressed in this message are those of the individual sender except where the sender expressly, and with the authority, states them to be the opinions of the Department of Emergency Services, Queensland.
Received on 2008-01-28 23:39:36 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.