Re: Subversion database corruption
Re: Subversion database corruption
- Subject: Re: Subversion database corruption
- From: Bill Bumgarner <email@hidden>
- Date: Thu, 4 Aug 2005 21:21:27 -0700
On Aug 4, 2005, at 3:25 PM, Andy Lee wrote:
On Aug 3, 2005, at 1:36 PM, Bill Bumgarner wrote:
I had a similar problem with Berkeley DB eating my subversion
repository. After speaking with the subversion developers about
it, I switched to the FSFS backend on all my repositories and have
not had another problem like it.
At least not a problem you know about. My boss pointed me to this
page: <http://svnbook.red-bean.com/en/1.1/ch05.html#svn-ch-5-
sect-1.3>. It seems to suggest that the reason the FSFS backend
doesn't get wedged by corrupted data is because it doesn't *detect*
it. Sounds to me like the version-control equivalent of compiling
with warnings turned off.
Or is that a mischaracterization?
Misinterpretation, I believe.
The "sensitivity to interruptions" means "how badly are you hosed
when someone yanks the power cord". BDB, like a lot of databases,
tends to be fairly sensitive to such events. The FSFS is designed to
be a bit more robust in the face of catastrophic failures by
sacrificing a bit of performance. In practice, this seems to mostly
translate to slower initial checkouts, but the operating speed from
that point on seems to be quite acceptable.
To be utterly fair, the Berkeley DB corruption problems encountered
with Subversion is greatly exacerbated, potentially entirely caused
by, the misuse of the BDB APIs by Subversion.
If anyone is looking for a decent db-backed code revision system,
take a look at monotone:
Monotone looks pretty interesting. So does Arch. But "db-backed"
isn't really a feature that is relevant to the implementation of a
revision control system. That is, whether or not the revision
control system uses a database, a proprietary file format or flat
files is only relevant in how difficult it is to recovery files from
a totally hosed repository. One of the very few advantages
(only? :-) of CVS is that the files in the repository were quite easy
to parse/recover.
Now, the whole distributed repository idea does seem pretty
interesting. Personally, I'm investigating SVK which is a
distributed repository layer on top of a standard Subversion
installation.
I keep coming back to Subversion, though, because the development
team is terribly smart, dedicated, and well funded. I don't really
have a need for distributed repositories, but that is a reflection of
the kind of development I'm doing. I can definitely see how it would
be incredibly useful for distributed development that is often common
to various open source projects or other kinds of similar development
methodologies.
Perhaps one of the biggest advantages to SVK is that it removes the
repository metadata from your workarea. And if I understand it
correctly, it treats the work area as an opaque collection, thus
removing any weirdness associated with managing NIBs, Keynote/Pages
documents, Core Data models, and any other directory-is-a-file kinds
of data.
b.bum
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden