Well, you don't have to convert it, but like I said, I did, and there
hasn't been a problem since. I've heard that with a larger staff and
more synchronous commits happening, that locking issues could occur, but
I've only got about a dozen people using the one I manage, so it's not
bad. Not to mention I don't trust the RedHat box or the BDB on it for
that matter...
Anyway, I had everyone check in there stuff so that I had the latest
version to work with, let's say it's version 500. Let's also say that
the backup that I have is version 450. I checked out the entire 500
version. I then used the svn diff command to make a patch between 500
and 450 on my fresh repository. I then applied that patch to the backup.
The unfortunate side effect is that you lose the history between 450 and
500. I did not commit anything yet.
Back on the Subversion server I backed up my repository, then used the
'svnadmin create --fs-type fsfs' command to create a new FSFS repository
with the same name as the one I just backed up. I then committed
everything that I patched and it went into the new FSFS repository. I
also had to check for files that were added between 450 and 500, but I
can do a simple Linux diff command for that and re-add them. Deleted
ones I didn't worry about so much, but rather left it up to the
developer to delete over again.
That was it. Like I said you do lose the history in that timeframe, but
it was better than losing anything more.
Hope that helps.
- Dustin
Alexandre Reis wrote:
>Dustin,
>
>After going through some backups last night I found one that was not
>corrupted, althought its dated (03/28/2005).
>
>I could use it do get a dump at least...
>
>So, what do I have to do now to convert my backend to FSFS?
>
>Thanks for your help,
>
>Alexandre M. Reis
>Systems Analyst
>Datasul Paranaense
>-----Original Message-----
>From: Dustin N. Jenkins [mailto:djenkins@invoqsystems.com]
>Sent: Tuesday, April 19, 2005 3:33 PM
>To: Alexandre Reis
>Cc: users@subversion.tigris.org
>Subject: Re: Corrupted Database
>
>Can you still check out and commit files to the repository(ies)? I had a
>similar experience about a month ago and ended up converting to a 1.1x
>FSFS (Filesystem based) repository. I haven't had a problem since. With
>the BDB backend, I used to recover at least twice a week.
>
>I'll share what I did if you reply saying you're interested, but I had a
>three-day-old backup to go off of, so if you don't have one, then this
>won't be useful and I apologize. The backup consisted of an svnadmin
>dump, and it's a good thing it was there. In my experience with the
>Subversion BDB, it's not worth trying to recover, but that's just me. I
>cut my losses and went with the upgrade. Ideally, and SQL backend would
>be nice, but that's in the (hopefully) near future.
>
>Anyway, if you're interested, let me know. I'd hate to waste your time
>if you're already stressing about the repositories' current state.
>
>Cheers,
>Dustin
>
>
>
>
>Alexandre Reis wrote:
>
>
>
>>Guys,
>>
>>I'm new to the list, so I'd first like to introduce myself and tell a bit
>>
>>
>of
>
>
>>my story with Subversion...
>>
>>I'm a developer for Datasul Paranaense, a corporate software developer's
>>local franchise. We develop custom solutions for Datasul ERP products.
>>
>>Our use of subversion consists on having every customer's projects on it,
>>allowing us to have effective group development, and also for security
>>
>>
>sake.
>
>
>>We've been using Subversion sice around August with no problems, including
>>
>>
>a
>
>
>>version upgrade (and a BDB version upgrade), which forced us to dump/load
>>the BDB database.
>>
>>After the dump/load, Subversion has corrupted quite frequently, but until
>>now, we could recover it with svnadmin recover.
>>
>>This time it really crashed, so I tried recovering it with db_recover -cve,
>>and it did recover itself fine.
>>
>>So I ran svnadmin verify on the repository, and it ran fine, until reaching
>>revision 629 (We're currently on revision 1925). It simply aborts after
>>getting to that revision.
>>
>>Same thing goes for svnadmin dump.
>>
>>I'd like to somehow dump this database and load it into a new database, to
>>get rid of this corrupt revision.
>>
>>I hope someone can help me out with this, as I've searched everywhere and
>>there doesn't seem to be a way to skip this revision while dumping, or
>>something that can fix it.
>>
>>Thank you all
>>
>>Alexandre M. Reis
>>Systems Analyst
>>Datasul Paranaense
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>>For additional commands, e-mail: users-help@subversion.tigris.org
>>
>>
>>
>>
>>
>>
>
>
>
--
Dustin N. Jenkins
Application Developer
Invoq Systems
216 - 852 Fort St.
Victoria, British Columbia
250.383.0311
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Apr 20 15:46:40 2005