This is my third post. Getting pret-ty desperate here...
Let's see. I have an svn repository with hundreds of thousands of
lines of code and about 2-years' worth of comments contained in it.
Since yesterday, svn has been failing in ***entirely random ways***.
Every time the only solution I have found has been to scrap the
current version of the repository, create a brand new repository with
sysadmin creaet, populate it from a recent repository dump with
sysadmin load, and repeat the changes done since that dump.
But every time this fix has been only temporary. Everything is fine
for a while, until suddenly svn begins to fail again, *unpredictably*
and in *entirely novel ways*.
In the first bout of failure all the error messages included the line
svn: Unable to open an ra_local session to URL
and sometimes also the line
svn: bdb: Program version 4.3 doesn't match environment version
After the reconstitution procedure described above (and correct
operations for some time), svn started failing again, but this time
the form of failure was silent: svn commands simply would hang
indefinitely, and would be unresponsive to kill -TERM.
I reconstituted everything again, and everything was fine for about 20
routine svn commands or so, and suddenly, again out of the blue,
failure. This time the error message is
No transaction named '6e' in filesystem '/home/jones/svn-repos/db'
Also, the command
svn co file:///home/jones/svn-repos SVN
again resulted in a hung process that had to be killed with kill
-KILL. In the above command the ./SVN directory did not yet exist, so
just for kicks, I created the ./SVN directory and repeated the
command. This time I immediately got a segfault (the first ever for
svn in my hands):
% svn co file:///home/jones/svn-repos SVN
zsh: 29440 segmentation fault svn co file:///home/jones/svn-repos SVN
In my 20+ years of programming and working on Unix I have *never* seen
anything like this.
The very helpful replies I have received to my previous posts have
focused on the details of the examples I have posted (e.g. BDB), which
is reasonable and understandable, but by now I hope it is clear that
these details are mostly irrelevant, because they change every time
and I still get unpredictable failures. The only constant across all
cases is svn's failure. (Curiously, svnadmin has performed
consistently throughout.)
What I desperately need are ***general*** troubleshooting techniques!
svn was working fine as of last Friday, and there has been *no change
whatsoever* to the installed software base since then. I didn't use
svn on Monday, and I spent all of yesterday fighting with it. I
thought I had the problem under control, when it resurfaced early this
morning.
I should point out that our sysadmin does a very good job of keeping
our system secure. In 6 years of operation it has never been
compromised, as far as we know. But this, of course, is always a
possibility. Then again, except for this problem I am having with
svn, the system is working fine. Out of about 30-40 regular users, no
one else has reported problems of the kind that would be consistent
with the hypothesis of a compromised system.
I could request that our sysadmin re-install svn from scratch, but
honestly, at this point I really can't tell whether this course of
action would increase or decrease the chances I will ever recover the
stuff in that repository. (And of course, if we simply re-installed,
we would never know what caused this disaster, so we would not have a
way to prevent it from happening again.)
Thanks a million!
kj
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed May 17 13:09:33 2006