RE: The /. article

From: Tom Lord [mailto:lord@regexps.com]
> Are you willing to discuss the
> corrections implied by this?

>Sure. Please note that Sean got some facts about arch wrong.

Thank you. Yes, that kinda happens. I'm glad you were able to correct
them; I didn't notice the errors.

>So far, the disaster recovery point clearly needs to be fixed and some
>other points need to be, at least, clarified. I'm listening.

I'd love to see the scope of the document changed from a "here's why arch is
universally better than Subversion" to something more like "here's how to
tell whether arch is better than Subversion for you".

I'd like to see a companion document put out by people knowledgable about
Subversion, and critiqued by you.

> I find it bizzare that "uses a database" would be considered a
> universally negative point by Tom, for example.

>It's simpler to implement, administer, write other tools for, inspect,
>grok...

All false. (Except for "implement", but I don't see you implementing a
filesystem, either.)

>When choosing betwen a relational, hash table, object or file system
>storage model, "file system" should always be the default. When you
>start needing to process a gazillion transactions per second, or to
>rapidly page in objects upon access, or keep lots of complex indexes
>-- then those other storage systems show their strengths and are worth
>giving up the convenience of a file system.

I just don't buy this. I'm sure it seems perfectly self-evident to you; it
doesn't to me. FSes are special-purpose databases; they're usually horribly
implemented databases, at that. Their main advantage is that they're almost
universally implemented as part of the OS, and thus preconfigured in a very
standard way.

They also usually have some halfway decent universal tools, but so do other
databases.

>Even that trade-off will
>become less clear as file systems continue to mature and acquire
>better semantics.

True. ReiserFS, for example, would actually be a useful FS for version
control, since it's reasonably efficient at storing and finding small chunks
of data.

>-t

-Billy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:04 2006