libsvn_ra is the library for accessing the repository. libsvn_wc is the library for managing your working copy. libsvn_client sits on top of those and provides convenience functionality like checking out and committing to/from a working copy, i.e. the operations typically presented by a user interface.

i am looking into doing internal version managment within a pike process. (ie, not just being a subversion client but maintaining the backend as well with some control over the data storage (like sitebuilder is doing with cvs))

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?

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-12 22:50: Subject: Re: subversion bindings

---

On Tue, Nov 12, 2002 at 10:25:04PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:

...

Bindings for libsvn_client exist, but probably needs some updating to work with the latest beta. Bindings for the other libraries (notably libsvn_ra) don't exist yet.

could you describe what that entails?

i take it that _ra is the serverprotocol library (ra_dav, ra_local and ra_pipe being different methods the server can handle. and that libsvn_client contains what is needed to write a subversion client.

i am looking into doing internal version managment within a pike process. (ie, not just being a subversion client but maintaining the backend as well with some control over the data storage (like sitebuilder is doing with cvs))

so i am mostly interrested in what ever is needed to handle the actual versioning stuff and backend.

greetings, martin.

/ Brevbäraren

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

well, that depends on what the possibilities are, if possible it would be nice if svn could be integrated into the existing sTeam backend. but using the svn backend would be feasable too if all the sTeam metadata can fit into there.

You can set any number of metadata on both files and directories.

keeping the existing backend would allow to have history optional, we also need to consider that we'd not be having one data repository but several small indepentend ones (every users data in sTeam should have it's own repository with independent branching unrelated to other data)

Branching in Subversion is just a copy operation with memory. There is no need to branch the entire repository if you don't want to (in fact you _can't_ branch the entire repository, since the branch also becomes part of the repository :). Any directory (or file even) can be branched individually.

Not that having multiple repositories is any particular problem either of course.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-13 00:19: Subject: Re: subversion bindings

---

On Tue, Nov 12, 2002 at 11:55:02PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:

...

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?

well, that depends on what the possibilities are, if possible it would be nice if svn could be integrated into the existing sTeam backend. but using the svn backend would be feasable too if all the sTeam metadata can fit into there.

keeping the existing backend would allow to have history optional, we also need to consider that we'd not be having one data repository but several small indepentend ones (every users data in sTeam should have it's own repository with independent branching unrelated to other data)

...

¹ Obviously not just yet, since I haven't actually written the glue for that lib yet, but it's next on my list. :-)

naturally, also note that i am not trying to push for things, but just inquiring at what state they are. sTeam history functionality is sort of a top wishlist item, not more yet...

greetings, martin.

/ Brevbäraren

good, that's usefull, does it keep history on the metadata too?

Naturally.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-13 00:50: Subject: Re: subversion bindings

---

On Wed, Nov 13, 2002 at 12:30:02AM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:

...

You can set any number of metadata on both files and directories.

good, that's usefull, does it keep history on the metadata too? (not that this is a required feature, but might be nice to have)

right now sTeam basicly has an object database written in pike using mysql as a backend storage and serializing the objects into it. (i have no clue of the details :-)

i suppose something similar would happen if the snv backend is used, but then taking advantage of svn to access older versions of objects.

yet i suspect that the way the serialization is done needs to change as right now the whole object including most metadata is serialized at once and for the history mechanism we'd need to ensure that content and metadata are handled sperately as we don't want diffs on the object serialization :-)

...

Any directory (or file even) can be branched individually.

ahh, that's a good thing.

greetings, martin.

/ Brevbäraren