On Tue, Apr 03, 2001 at 07:20:08AM +0000, Tripp Lilley wrote:
> On Tue, 3 Apr 2001, Greg Stein wrote:
> > In this case, it isn't a premature optimization. We know that data access
> > will be a large issue. Second, the choice of binary vs text was independent
> > of our main decision point: programmer productivity. Why implement a (text)
> > database, when we already have a database ready and waiting for us?
>...
> Is svn storing the plaintext head revision and plaintext deltas "in the
> filesystem", or "in the DB"?
Everything in the DB (under the API of the "SVN filesystem (FS)").
> Again calling on my experience with Perforce,
> I know that they store the -source- itself in RCS form reverse-delta
> plaintext files. They then store the -metadata- in "some binary format".
> Should the metadata become corrupt, you will not have the entire
> integration / submission / etc., history, but you will at least have the
> files themselves, and the individual revision history of the files (which
> is obviously better than zilch, and usually sufficient relief for anyone
> suffering a catastrophic failure in the absence of regular backups).
Depending on what gets hit, it could be a minor impact, or it could be a
large impact. But we are not designing for disk failure or filesystem
corruption. I relegate that problem and its resolutions to the operating
system. There is only so much you can defend against before you simply toss
out the operating system and code your own server in assembly. Oh, and toss
out the BIOS and the firmware on your hard drives. Oh, and make sure you use
redundancy across your DIMMs to protect against bad DIMMs. And ... ;-)
The counter to my extreme example is simply that you have to trust
*something* in all the software that builds up your system. People just like
to draw the lines of trust in different areas. The SVN team has chosen to
trust Apache, APR, Neon, Expat, and DB. Those are five *huge* pieces of
code, which is why SVN is relatively small for what it accomplishes.
[ a line count shows 45 kloc ]
> If you're at present storing -everything- in the DB, it might be at least
> worthwhile to investigate such separation as described above for "a future
> release".
Subversion 2.0 will have a pluggable database backend. My two personal goals
for 2.0 are the database and (better) WebDAV/DeltaV compatibility. I'll use
any veto power I can to ensure that 2.0 doesn't go out the door without
those features :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:27 2006