You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Brian C. Van Essen" <va...@cs.washington.edu> on 2005/06/10 21:35:43 UTC
Repository died after a "successful" add and commit
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello, I was trying to get my advisor to use our subversion
repository today and during what seemed a normal sequence of
operations, the repository has corrupted itself and we are being
forced to pull a backup. I am trying to figure out what went wrong,
so here is the sequence of events.
Background:
Two of us use the repository mainly via ssh remote access, and have
had no problems.
Today's sequence of events:
Today, I had our advisor checkout the repository via a "file://" URL
from a nfs mounted drive.
He then added a directory named proposal to the top of the repository
and two files, proposal.tex and proposal2.tex, to his local copy.
Then he used the svn add command to add the files and directory to
the repository.
Finally he committed the files, which brought the repository revision
to 91.
Next he modified one of the newly added files, and attempted to
commit it to the repository.
This commit failed with an error message along the lines of:
Commit Failed
File not found: transaction'50', path '/proposal/proposal2.tex'
At this point, knowing that something was wrong, I logged into
another machine and tried to checkout the repository under my account.
I executed the command svn co file:///path/to/repository and it
pulled version 90 out of the repository.
Seeing that this was a revision behind what my advisor just added I
issued the command svn stat -u, which responded:
svn: No transaction named '50' in filesystem '/projects/lis/rapid/
svnrep/db'
Then after looking around on the net and not finding many useful
tips, I tried:
tebo:~/tmp_sb/svnrep vanessen$ svn update --revision 91
svn: No transaction named '50' in filesystem '/projects/lis/rapid/
svnrep/db'
tebo:~/tmp_sb/svnrep vanessen$ svn update --revision 90
At revision 90.
tebo:~/tmp_sb/svnrep vanessen$ svn update --revision 89
U algorithms/FFT/FFT.test.c
Updated to revision 89.
tebo:~/tmp_sb/svnrep vanessen$ svn update --revision 90
U algorithms/FFT/FFT.test.c
Updated to revision 90.
So, it seems that version 91 is screwed, but I can work with previous
versions.
So, I tried to see if there were some uncommited transactions, but
svn lstxns retruned nothing.
So, I tried svnadmin verify:
tebo:~/tmp_sb/svnrep vanessen$ svnadmin verify /projects/lis/rapid/
svnrep
* Verified revision 0.
* Verified revision 1.
* Verified revision 2.
* Verified revision 3.
* Verified revision 4.
* Verified revision 5.
* Verified revision 6.
* Verified revision 7.
* Verified revision 8.
* Verified revision 9.
* Verified revision 10.
* Verified revision 11.
* Verified revision 12.
* Verified revision 13.
* Verified revision 14.
* Verified revision 15.
* Verified revision 16.
* Verified revision 17.
* Verified revision 18.
* Verified revision 19.
* Verified revision 20.
* Verified revision 21.
* Verified revision 22.
* Verified revision 23.
* Verified revision 24.
* Verified revision 25.
* Verified revision 26.
* Verified revision 27.
* Verified revision 28.
* Verified revision 29.
* Verified revision 30.
* Verified revision 31.
* Verified revision 32.
* Verified revision 33.
* Verified revision 34.
* Verified revision 35.
* Verified revision 36.
* Verified revision 37.
* Verified revision 38.
* Verified revision 39.
* Verified revision 40.
* Verified revision 41.
* Verified revision 42.
* Verified revision 43.
* Verified revision 44.
* Verified revision 45.
* Verified revision 46.
* Verified revision 47.
* Verified revision 48.
* Verified revision 49.
* Verified revision 50.
* Verified revision 51.
* Verified revision 52.
* Verified revision 53.
* Verified revision 54.
* Verified revision 55.
* Verified revision 56.
* Verified revision 57.
* Verified revision 58.
* Verified revision 59.
* Verified revision 60.
* Verified revision 61.
* Verified revision 62.
* Verified revision 63.
* Verified revision 64.
* Verified revision 65.
* Verified revision 66.
* Verified revision 67.
* Verified revision 68.
* Verified revision 69.
* Verified revision 70.
* Verified revision 71.
* Verified revision 72.
* Verified revision 73.
* Verified revision 74.
* Verified revision 75.
* Verified revision 76.
* Verified revision 77.
* Verified revision 78.
* Verified revision 79.
* Verified revision 80.
* Verified revision 81.
* Verified revision 82.
* Verified revision 83.
* Verified revision 84.
* Verified revision 85.
* Verified revision 86.
* Verified revision 87.
* Verified revision 88.
* Verified revision 89.
* Verified revision 90.
svn: No transaction named '50' in filesystem '/projects/lis/rapid/
svnrep/db'
Seeing that was screwed up, and not finding any other pointers from
your FAQs, discussions, or the web, I tried the one recovery tool
that is described in your manual.
tebo:~/tmp_sb/svnrep vanessen$ svnadmin recover /projects/lis/rapid/
svnrep
Repository lock acquired.
Please wait; recovering the repository may take some time...
Recovery completed.
svn: Berkeley DB error while opening environment for filesystem /
projects/lis/rapid/svnrep/db:
DB_RUNRECOVERY: Fatal error, run database recovery
svn: bdb: PANIC: fatal region error detected; run recovery
tebo:~/tmp_sb/svnrep vanessen$ svnadmin verify /projects/lis/rapid/
svnrep
svn: Berkeley DB error while opening environment for filesystem /
projects/lis/rapid/svnrep/db:
DB_RUNRECOVERY: Fatal error, run database recovery
svn: bdb: PANIC: fatal region error detected; run recovery
So, now it seems that the whole database is screwed and I am hoping
that our systems group has a current backup.
By the way, our linux servers are running version 1.1.4 of subversion.
So, any ideas of why this happened, and how it can our could be
corrected would be greatly appreciated.
Thanks,
Brian Van Essen
vanessen@cs.washington.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFCqgevoantcYzeJdYRAhfzAKCC6jZuo+wvMk3jIHs6ya6cDlrLEwCfVjOv
jZKhHUQ1qxKOmjxZSilUZW8=
=eXBy
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Repository died after a "successful" add and commit
Posted by Nicolas Goutte <ni...@snafu.de>.
On Monday 13 June 2005 14:43, Nicolas Goutte wrote:
> On Monday 13 June 2005 12:25, Olivier Sannier wrote:
> > Nicolas Goutte wrote:
> > >On Friday 10 June 2005 23:35, Brian C. Van Essen wrote:
> > >>Hello, I was trying to get my advisor to use our subversion
> > >>repository today and during what seemed a normal sequence of
> > >>operations, the repository has corrupted itself and we are being
> > >>forced to pull a backup. I am trying to figure out what went wrong,
> > >>so here is the sequence of events.
> > >>
> > >>Background:
> > >>Two of us use the repository mainly via ssh remote access, and have
> > >>had no problems.
> > >>
> > >>Today's sequence of events:
> > >>Today, I had our advisor checkout the repository via a "file://" URL
> > >>from a nfs mounted drive.
> > >
> > >Have you read the FAQ and the handbook? As far as I have understood, it
> > > is written there that you cannot use Berkeley DB on NFS, not even on a
> > > NFS system claiming to support Berkeley. (And from the logs below, you
> > > *are* using Berkeley, not FSFS!)
> >
> > Well, you could, but you would have to NOT use the file:// URL, as this
> > is the source of the problem.
>
> Well, sorry, buf that is not what the Subversion FAQ says.
>
> It tells that Berkeley DB does not work over NFS and the pointed document
> http://www.sleepycat.com/docs/ref/env/remote.html
> tells the same.
Ah, I think I have understood what you meant. The server is the only one
accessing the database, so it could work.
>
> So I doubt that it depends on the access method used by the Subversion
> client. If the server uses Berkeley but the database is accessed by NFS,
> you should probably get the same problem.
However for Linux, there is also a note at the bottom telling that Berkeley
will not work at all on Linux with NFS (similar for FreeBSD).
>
> Have a nice day!
>
> > Cheers
> > Olivier
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Repository died after a "successful" add and commit
Posted by Steve Greenland <st...@lsli.com>.
On Mon, Jun 13, 2005 at 02:57:44PM +0200, Olivier Sannier wrote:
> Well, I think it is more a problem of multiple access to the same file,
> by different processes. So if you have a single acces point (Apache, or
> svnserve) and no one uses file:// then it should be fine. That's how I
> understand it, but I may be wrong.
Nope: Consider two users hitting the repo at the same time.
Steve
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask
about Exchange Server next.
-- (Stolen from the net)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Repository died after a "successful" add and commit
Posted by Olivier Sannier <ob...@free.fr>.
Nicolas Goutte wrote:
>On Monday 13 June 2005 12:25, Olivier Sannier wrote:
>
>
>>Nicolas Goutte wrote:
>>
>>
>>>On Friday 10 June 2005 23:35, Brian C. Van Essen wrote:
>>>
>>>
>>>>Hello, I was trying to get my advisor to use our subversion
>>>>repository today and during what seemed a normal sequence of
>>>>operations, the repository has corrupted itself and we are being
>>>>forced to pull a backup. I am trying to figure out what went wrong,
>>>>so here is the sequence of events.
>>>>
>>>>Background:
>>>>Two of us use the repository mainly via ssh remote access, and have
>>>>had no problems.
>>>>
>>>>Today's sequence of events:
>>>>Today, I had our advisor checkout the repository via a "file://" URL
>>>>
>>>>
>>>>from a nfs mounted drive.
>>>
>>>Have you read the FAQ and the handbook? As far as I have understood, it is
>>>written there that you cannot use Berkeley DB on NFS, not even on a NFS
>>>system claiming to support Berkeley. (And from the logs below, you *are*
>>>using Berkeley, not FSFS!)
>>>
>>>
>>Well, you could, but you would have to NOT use the file:// URL, as this
>>is the source of the problem.
>>
>>
>
>Well, sorry, buf that is not what the Subversion FAQ says.
>
>It tells that Berkeley DB does not work over NFS and the pointed document
>http://www.sleepycat.com/docs/ref/env/remote.html
>tells the same.
>
>So I doubt that it depends on the access method used by the Subversion client.
>If the server uses Berkeley but the database is accessed by NFS, you should
>probably get the same problem.
>
>
Well, I think it is more a problem of multiple access to the same file,
by different processes. So if you have a single acces point (Apache, or
svnserve) and no one uses file:// then it should be fine. That's how I
understand it, but I may be wrong.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Repository died after a "successful" add and commit
Posted by Nicolas Goutte <ni...@snafu.de>.
On Monday 13 June 2005 12:25, Olivier Sannier wrote:
> Nicolas Goutte wrote:
> >On Friday 10 June 2005 23:35, Brian C. Van Essen wrote:
> >>Hello, I was trying to get my advisor to use our subversion
> >>repository today and during what seemed a normal sequence of
> >>operations, the repository has corrupted itself and we are being
> >>forced to pull a backup. I am trying to figure out what went wrong,
> >>so here is the sequence of events.
> >>
> >>Background:
> >>Two of us use the repository mainly via ssh remote access, and have
> >>had no problems.
> >>
> >>Today's sequence of events:
> >>Today, I had our advisor checkout the repository via a "file://" URL
> >>from a nfs mounted drive.
> >
> >Have you read the FAQ and the handbook? As far as I have understood, it is
> >written there that you cannot use Berkeley DB on NFS, not even on a NFS
> >system claiming to support Berkeley. (And from the logs below, you *are*
> >using Berkeley, not FSFS!)
>
> Well, you could, but you would have to NOT use the file:// URL, as this
> is the source of the problem.
Well, sorry, buf that is not what the Subversion FAQ says.
It tells that Berkeley DB does not work over NFS and the pointed document
http://www.sleepycat.com/docs/ref/env/remote.html
tells the same.
So I doubt that it depends on the access method used by the Subversion client.
If the server uses Berkeley but the database is accessed by NFS, you should
probably get the same problem.
Have a nice day!
>
> Cheers
> Olivier
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Repository died after a "successful" add and commit
Posted by Olivier Sannier <ob...@free.fr>.
Nicolas Goutte wrote:
>On Friday 10 June 2005 23:35, Brian C. Van Essen wrote:
>
>
>>Hello, I was trying to get my advisor to use our subversion
>>repository today and during what seemed a normal sequence of
>>operations, the repository has corrupted itself and we are being
>>forced to pull a backup. I am trying to figure out what went wrong,
>>so here is the sequence of events.
>>
>>Background:
>>Two of us use the repository mainly via ssh remote access, and have
>>had no problems.
>>
>>Today's sequence of events:
>>Today, I had our advisor checkout the repository via a "file://" URL
>>from a nfs mounted drive.
>>
>>
>
>Have you read the FAQ and the handbook? As far as I have understood, it is
>written there that you cannot use Berkeley DB on NFS, not even on a NFS
>system claiming to support Berkeley. (And from the logs below, you *are*
>using Berkeley, not FSFS!)
>
Well, you could, but you would have to NOT use the file:// URL, as this
is the source of the problem.
Cheers
Olivier
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Repository died after a "successful" add and commit
Posted by Nicolas Goutte <ni...@snafu.de>.
On Friday 10 June 2005 23:35, Brian C. Van Essen wrote:
> Hello, I was trying to get my advisor to use our subversion
> repository today and during what seemed a normal sequence of
> operations, the repository has corrupted itself and we are being
> forced to pull a backup. I am trying to figure out what went wrong,
> so here is the sequence of events.
>
> Background:
> Two of us use the repository mainly via ssh remote access, and have
> had no problems.
>
> Today's sequence of events:
> Today, I had our advisor checkout the repository via a "file://" URL
> from a nfs mounted drive.
Have you read the FAQ and the handbook? As far as I have understood, it is
written there that you cannot use Berkeley DB on NFS, not even on a NFS
system claiming to support Berkeley. (And from the logs below, you *are*
using Berkeley, not FSFS!)
(...)
> Recovery completed.
> svn: Berkeley DB error while opening environment for filesystem /
> projects/lis/rapid/svnrep/db:
> DB_RUNRECOVERY: Fatal error, run database recovery
> svn: bdb: PANIC: fatal region error detected; run recovery
> tebo:~/tmp_sb/svnrep vanessen$ svnadmin verify /projects/lis/rapid/
> svnrep
> svn: Berkeley DB error while opening environment for filesystem /
> projects/lis/rapid/svnrep/db:
> DB_RUNRECOVERY: Fatal error, run database recovery
> svn: bdb: PANIC: fatal region error detected; run recovery
(...)
Have a nice day!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org