Re: Blue Sky: Scripting Language / SQL database ?

Greetings Again :-)

I've had a slight rethink .... what I am really wanting is to leave subversion entirely as it is and interact with it in two ways.

Firstly to communicate with SVN via its API (1) to do things like check things out and in etc... which I can do by simply using the command line interface or with SWIG allowing intergration with whatever applications you want.

The other thing I'm considering is keeping a syncronised SQL database (2) going with Subversion which could be used to do things like allocate custom permissions to resources, more complicated searching and the storage of custom "resource types". This is very similar to the mod_dav_dbms architecture that allows searching (DASL) to DAV resources. All that is required is that when subversion commits a change, (eg a document's locations is changed) that it spawns a call to a wrapper class that logs this to the database.

I know (1) is possible what about (2)? I will continue to read the documentation on the subject and Subversion in general :-)

Awesome, Z.

  ----- Original Message -----
  From: Zitan Broth
  To: dev@subversion.tigris.org
  Sent: Sunday, April 27, 2003 11:36 PM
  Subject: Blue Sky: Scripting Language / SQL database ?

  Greetings All,

  Been having a look at Subversion and it is an excellent open source project alright, far more flexible than CVS, and particularly awesome to support DAV and DeltaV. And my interest in Subversion comes *especially* from the DeltaV support. To be able integrate Subversion with into a web service-based architecture it would require some extra functionality mentioned in the "Future" section of the Subversion Design doc. My serving side scripting language of choice is PHP but I'm sure you could achieve a bridge to PHP from Perl also.

  With a scripting language glue layer in between the Subversion "business logic" (eg how to implement DeltaV, DAV) and the current "persistance" layer (currently Berkely DB) it would be possible to take advantage of the logic that handles DAV and DeltaV but extend the logic and change how things are persisted in powerful ways (ie write another backend), say for example persisting part of the data in an SQL database (metadata, text docs, collections even and the other part (larger media files) in a file repository, and so on. It would also mean that organisations would likely extend the mod_dav backend via svn also, so that their custom backends could support DeltaV where required. A language like PHP supports almost every SQL database under the sun as well as being able to call Perl, Pthyon, Java and even .NET allowing integration into any platform or backend desired.

  I'm installing a windows version locally of Subversion now and will look over the API documentation (svn_fs.h), however I'm (not yet) a C developer. So I'm interested to know what the interest in this project extension? How hard would it be to implement? Is work currently underway? I guess if the architecture is well abstracted (and Subversion looks to be an excellently managed project ;)) it would be a matter of editing the current API between the logic and the persistance to call a series of classes which are currently blank but would be filled in by the developers as required. Have I got the "right end of the stick" here or is the work far more complicated (eg is part of the logic embedded with the persistance layer interface)?

  Any comments a greatly appreciated.

  Awesome,
  Z.
Received on Mon Apr 28 05:28:46 2003