On Oct 13, 2004, at 4:29 AM, Tobias Ringström wrote:
> Dave Camp wrote:
>
>> At this point, I've given up. The repository was brand new (we just
>> switched to subversion on Monday) so starting over wasn't a big deal.
>> However, it is somewhat distressing that the database can't be fixed.
>> I was under the impression that the journalling was supposed to
>> prevent that... especially considering that the file system it's on
>> is journaled as well (Mac OS X Server with HFS+).
>
> I've heard about almost exactly this problem several times recently,
> and the common denominator is OS X. Two people even claimed that the
> last access to the repository was an hour before the crash, and the
> repository still became corrupt. I would say that such a thing is
> impossible, but when it has happened twice I'm not so sure...
We discovered yesterday (after a number of non-fatal database wedges)
that the umask for bash and tcsh were not correct. We have fixed that
(set to 002 now) and we'll see how day 3 on subversion goes... :-)
It would be nice if subversion could give more useful error messages in
this case.
> When I see problems such as this one, I usually fix them by removing
> the __db.* and log.* files in the db directory of the repository and
> then dump and load the old repository into a new one and copy the
> contents of conf/ and hooks/. The dump+load is *probably* not
> necessary, but it's safer.
Thanks for the tip. The next task on my list is a daily cron job for
hotbackup.py to guarantee we don't ever lose more than a day's worth of
changes.
> Try to upgrade to 1.1.0 and use FSFS (svnadmin create --fs-type fsfs
> repos) if at all possible.
We are already using 1.1.0 (we waited for it to ship before switching
to subversion).
It's not immediately obvious from what I've read that FSFS is "worthy"
of storing my source yet (i.e. has it been proven to be completely
stable) or how it performs better in failure cases. But that could just
be my ignorance. I'll have to go read more about FSFS I guess... it's
been a while since I first looked at it.
Thanks,
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Oct 13 16:26:49 2004