You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Lester Caine <le...@lsces.co.uk> on 2005/10/17 06:56:27 UTC
SQL support
I've been tracking this project for some time, but have not moved
anything over yet since I'm still having to use CVS with sourceforge and
so my local CVS server makes sense.
I would like to start thinking about a switch over, but the only thing
that is really stopping me is the lack of a better database back end. I
do not intend to start running a second database engine ( for reasons
that will be obvious from my sig ;) ) and so I am wondering if there is
any movement happening on a proper SQL interface currently, or are the
talks just continuing?
I think that a move to something that can be used as a source of data by
other database engines - with things like logging in database tables
would enhance Subversion and improve take up!
--
Lester Caine
-----------------------------
L.S.Caine Electronic Services
Treasurer - Firebird Foundation Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SQL support
Posted by Michael Brouwer <mb...@gmail.com>.
On 10/17/05, Lester Caine <le...@lsces.co.uk> wrote:
> Simple things like a view of number of commits by user over timeframe -
> linked to their profile in a framework user database. Access to a list
> of who modified a particular file. All the sorts of things that can be
> built and filtered as SQL queries without having to write code.
How is writing SQL not writing code? It's still code it's just not C
code, but SQL code.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SQL support
Posted by "C. Michael Pilato" <cm...@collab.net>.
Brian Behlendorf <br...@collab.net> writes:
> On Mon, 17 Oct 2005, Lester Caine wrote:
> > Simple things like a view of number of commits by user over
> > timeframe -
> > linked to their profile in a framework user database. Access to a
> > list of who modified a particular file. All the sorts of things that
> > can be built and filtered as SQL queries without having to write
> > code.
>
> Sounds like much of the value of being in SQL lies in reporting, not
> in production; would it be better to take logs of commits made against
> the current database (content and metadata) and process them into
> commits against a relational database with a SQL schema optimized for
> reporting?
Yep. ViewCVS's svndbadmin tool does exactly this, basically crawling
a repository for commit information (in full, or incrementally) and
squirreling that away into a MySQL database. ViewCVS then provides a
Web-based query interface into that database. I can't vouch for the
completeness of SQL-stored data -- I imagine that since svndbadmin was
modeled after cvsdbadmin, that there are piece of information not
stored. But it might be a good starting point for someone interested.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SQL support
Posted by Brian Behlendorf <br...@collab.net>.
On Mon, 17 Oct 2005, Lester Caine wrote:
> Simple things like a view of number of commits by user over timeframe -
> linked to their profile in a framework user database. Access to a list of who
> modified a particular file. All the sorts of things that can be built and
> filtered as SQL queries without having to write code.
Sounds like much of the value of being in SQL lies in reporting, not in
production; would it be better to take logs of commits made against the
current database (content and metadata) and process them into commits
against a relational database with a SQL schema optimized for reporting?
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SQL support
Posted by Lester Caine <le...@lsces.co.uk>.
Greg Hudson wrote:
> On Mon, 2005-10-17 at 07:56 +0100, Lester Caine wrote:
>
>>I think that a move to something that can be used as a source of data by
>>other database engines - with things like logging in database tables
>>would enhance Subversion and improve take up!
>
> Can you explain how you see Subversion's back end storage being used by
> other database engines?
Simple things like a view of number of commits by user over timeframe -
linked to their profile in a framework user database. Access to a list
of who modified a particular file. All the sorts of things that can be
built and filtered as SQL queries without having to write code.
> One of the issues with this vision is that Subversion's repository model
> is DAG-structured, and modelling DAGA data in a database so that it can
> be efficiently queried is difficult. Storing all the expanded-out paths
> as database keys is a non-starter, due to Subversion's O(1) copy model
> and its model of revisions as trees with some nodes shared with previous
> trees.
That may be the case, and elements of the stored data may have to be
stored raw, but that does not prevent the data being stored in a
database. An engine with good UDF/SP support can provide the sort of
tree view you are talking about direct from the database - but that
would create the same non-generic problems that currently occure ;)
> Revision metadata--revprops and changed-path lists--could be used by
> outside code straightforwardly enough, but that's not a great deal of
> value.
In the bulk of cases, that is the sort of data that would be useful to
have. A user profile can query what they modified and when they modified
it from anything that handles an SQL query interface - without having to
build custom code to access it?
--
Lester Caine
-----------------------------
L.S.Caine Electronic Services
Treasurer - Firebird Foundation Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SQL support
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2005-10-17 at 07:56 +0100, Lester Caine wrote:
> I think that a move to something that can be used as a source of data by
> other database engines - with things like logging in database tables
> would enhance Subversion and improve take up!
Can you explain how you see Subversion's back end storage being used by
other database engines?
One of the issues with this vision is that Subversion's repository model
is DAG-structured, and modelling DAGA data in a database so that it can
be efficiently queried is difficult. Storing all the expanded-out paths
as database keys is a non-starter, due to Subversion's O(1) copy model
and its model of revisions as trees with some nodes shared with previous
trees.
Revision metadata--revprops and changed-path lists--could be used by
outside code straightforwardly enough, but that's not a great deal of
value.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org