Mark Phippard wrote:
> m christensen <dfs@xmission.com> wrote on 08/11/2004 06:31:08 PM:
>
>> Subversion preforms a very specific task from a database standpoint the
>> flexibility complex SQL queries provide are useless.
>
> I disagree. One of the reasons I think a SQL implementation would be
> useful is that it would allow for ad-hoc querying and reporting which is
> currently missing from Subversion and present in many commercial tools.
If the SQL schema is anything like the BDB schema, then I doubt you'll be
able to do much "ad-hoc" querying (without the SQL queries becoming
intolerably complex).
>> The only 'advantage' generic database support would provide would be to
>> allow people to "muck" with the data directly.
>> That is a bad idea IMHO.
>
> Certainly, but just because BDB is not accessible does not make that a
> feature of BDB. A certain amount of common sense will always apply.
Very much so. BDB isn't inaccessible if you don't want it to be. I've
"mucked" with several repositories to rescue them after they became damaged.
And am currently working on a primitive "svn obliterate" based on "mucking"
with the BDB files.
>> Subversion provides an easily automated command line interface and APIs
>> to provide an abstracted interface to the
>> logical information describing a repository, what more would anyone
>> need? What can of worms does that open?
>>
>
> I think there are a lot of benefits a SQL implementation could bring. I
> have already mentioned some, here are some more:
>
> 1) Backup and recovery. Most enterprises already have this taken care of
> for their databases. Subversion could slide right into this framework.
True. "Just back it up like a normal FooSQL database" is simpler than "learn
about svnadmin hotcopy", if you already maintain a FooSQL infrastructure.
> 2) Stability. A SQL implementation is not inherently more stable than a
> native file system or BDB, but many enterprise managers will still feel
> more comfortable with one.
... and will have more experience with tuning such things to *be* stable,
than with BDB.
> 3) Scalability. All sort of options would be opened up, from clustering
> and high-availability, to separating the Subversion "application server"
> from the physical database server.
Now, that *is* an interesting thought...
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Aug 12 03:32:07 2004