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

Re: No transaction name 'a80' running on NT4 system

From: Max Bowsher <maxb_at_ukf.net>
Date: 2004-08-11 02:49:28 CEST

stephen meechan wrote:
> Subversion 1.0.5 using svnserve.
>
> OS NT 4.0 Server with SP 6.
>
> Clients are Windows 2000 with TortoiseSVN.
>
> The repository was migrated from CVS 10 days ago and was just gradually
> being put to use.
>
> When trying to check in a change there was an error reported that needed
DB
> recovery, unfortunately the person running it didn't save the exact
message.
> I stopped svnserve and ran svnadmin recover which came back ok with
revision
> at 13211.
>
> Retrying the commit though came back with an error "No transaction named
> 'a80'. DB needs recovery". I ran recovery again, but this time also
verify.
> Verify goes through to 13210 and then reports the same error.
>
> svnadmin lstxns has 4 transactions, a4s is from august 3rd, a82, a83 and
a84
> look like the original commit plus the retries.
>
> svnadmin dump worked up to revision 13210 and I'm rebuilding the db now
with
> that. 13210 has the files that were changed Monday, so 13211 would only be
> files changed Tuesday. The server was rebooted late Monday, other than
that
> there are no errors recorded.
>
> Is it ok to use svnserve with NT4? I cant see anything on the site or
> mailing list to indicate there might be problems.

It should be OK.

> Are there any tools to find out what has gone wrong with the db?

There are few who have taken the time to comprehend the schema of the
subversion database. I'm one of them :-)

You've provided lots of detail (thanks!), from which I can tell that the
failed commit has somehow been recorded in the revisions database, but its
record in the transactions database is missing. It's hard to say how this
corruption happened, or why the original failure occurred.

Was anything happening to the server which could have caused the failure?
I'm afraid it seems likely that the cause will remain a mystery :-(

> It looks like svnadmin hotcopy doesn't detect the error which implies I
> could overwrite a good backup with one that has problems and not know it
> unless I also do verify every time? Or is there a better way of doing it?

Unfortunately, this is quite correct. Hotcopy only verifies that the result
is a valid to Berkeley DB. It doesn't check that the data stored within the
Berkeley DBs is valid to subversion.

Max.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Aug 11 02:53:46 2004

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