[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Time to open SQL can-of-worms again?

From: Mark Phippard <MarkP_at_softlanding.com>
Date: 2004-08-12 15:25:56 CEST

"Max Bowsher" <maxb@ukf.net> wrote on 08/11/2004 09:31:36 PM:

> Mark Phippard wrote:
> > m christensen <dfs@xmission.com> wrote on 08/11/2004 06:31:08 PM:
> >
> > 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).

You are probably correct, but I was thinking more of "reports". Like show
me the # of commits per week for user xyz between June 2004 and July 2004.
 Or a graph of commits by programmer over a time period. The schema would
likely be able to provide this information rather easily.

> >> 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.

My point was that mucking with any database should be a last resort. If I
had to do it, I would rather do it with my SQL database. Funny that you
should reply, because I almost mentioned your name as being 1 of maybe 2
people in the world capable of fixing a Subversion BDB database.

> >
> > 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.

I actually think that fsfs now has the best backup story because it lends
itself so well to an incremental backup. However, most enterprises
already have database backup and recovery in place and would feel most
comfortable with that as the solution.

Mark

_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Aug 12 15:26:22 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.