Ok, I think I misunderstood you a bit when you said that the pike process would "maintain the backend". You do want to use the existing Subversion backend (which uses BerkeleyDB to store the data on disk), right?
Then your pike process can¹ use libsvn_ra to access the versioned contents of the repository database directly without involving a server, by using the "local" repository access mechanism which accesses the db files in the filesystem directly. Unless you also set up a DAV server, normal filesystem permissions will restrict access to the repository.
You could actually even use libsvn_client, since it can of course use the local repository access too, but that would mean that you'd have to check everything out into files, like Sitebuilder does.
¹ Obviously not just yet, since I haven't actually written the glue for that lib yet, but it's next on my list. :-)
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2002-11-12 23:27: Subject: Re: subversion bindings
On Tue, Nov 12, 2002 at 11:05:08PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
I'm slightly confused. Do you want to implement your own subversion server? From scratch? Or did you intend to use local access with an incompatible backend, thus making interoperability with normal svn clients impossible?
What is the problem you are trying to solve?
the general problem to be solved is version managment for the user data in sTeam (www.open-steam.org)
currently that data is stored in a custom mysql backend. the sTeam server itself is the only client that needs access to this data directly (everyone else does it via sTeam) allowing other svn client to access it is possible only if the subversion protocols can be integrated into sTeams access control managment. (accessing the repository bypassing those access controls should not be possible (except for maybe root like access))
creating a new svn server could be one possible way of doing it, with reusing as much of the existing code as possible, using our existing backend as an option and acting as a regular svn server to others maybe in the future.
another possible solution would be to restrict the history to individual objects without any corelation among them (tags/branching) for that the ability to read and write the rcs format would suffice.
i am curious if the svn libs can help to go beyond that.
greetings, martin.
/ Brevbäraren