Re: Subversion C API

The FS API, svn_fs_ and svn_repos_, provides access to a repository on
the local filesystem. It provides a transactional API to commits:
create a txn, populate the txn, commit or delete the txn. The servers
svnserve and mod_dav_svn use this API.

The RA API, svn_ra_, provides access to a repository via an URL such as
http://, svn://, file:// etc. Usually this repository will be on a
remote server running svnserve or mod_dav_svn. It also provides a
transactional API to commits but is more restricted: the FS API provides
random access to the txn while the RA API requires an ordered pass over
the txn. The client svnmucc uses this API.

The client API, svn_client_, provides access to a repository via a
working copy or via an URL. It provides a higher level API that does
not expose transactions, but instead provides functions to make a
commit, do an import, etc. The client svn uses this API.

If you want network access, or you want to use Subversion's
authentication/authorization, then use the RA or client APIs. If you
want local access, and more freedom with transaction handling, then use
the FS API.

"Ren Wang" <renwang101_at_gmail.com> writes:

> Hi Bert,
>
>
>
> Thank you very much for the detail explanations.
>
>
>
> We have been thinking about the option to develop our own repository layer
> vs subversion API file:/// <file:///\\> repository API (libsvn_fs). This is
> why we are looking for programming guide and sample code for supporting our
> use cases. So far, we only have the test code from subversion, such as
> test_fs project which is not enough for us.
>
>
>
> I will take a look of the svnmucc code.
>
>
>
> Regards,
>
>
>
> Ren
>
>
>
> From: Bert Huijben [mailto:bert_at_qqmail.nl]
> Sent: Sunday, November 8, 2015 12:28 PM
> To: 'Ren Wang' <renwang101_at_gmail.com>; users_at_subversion.apache.org
> Subject: RE: Subversion C API
>
>
>
> Mod_dav mostly uses the repository layer api. In a few specific cases it
> goes into the fs layer directly. sometimes because something isn't mapped,
> but in other cases because mod_dav was developed very early in the
> development process and the repository layer wasn't as complete as it is
> today.
>
>
>
> But is the client layer really that expensive for you that you can't use it?
> Did you measure it?
>
>
>
> I can't imagine usecases where the performance is that critical that you
> really can't afford the thin layer that the file:/// <file:///\\>
> repository api has, but don't want a specialized datastore 100% optimized
> for your usecase.
>
>
>
> I can think of a few cases where you might want to avoid the overhead of
> having a working copy, but even there the costs aren't usually that high
> that it makes sense to spend a lot of time to develop something else.
>
> (And in many cases the still private API behind svnmucc can already help you
> there)
>
>
>
> Bert
>
>
>
> From: Ren Wang [mailto:renwang101_at_gmail.com]
> Sent: vrijdag 6 november 2015 19:44
> To: users_at_subversion.apache.org <mailto:users_at_subversion.apache.org>
> Subject: Subversion C API
>
>
>
> I have posted the same question to the stackoverflow, here it is. Looking
> forward to hear from you:
>
>
>
> We are considering to use Subversion as the file system layer to store
> version enabled documents. Since the security function will be handled by
> other code, I am considering to directly use the Subversion FS C API layer.
> I wonder if there any good sample code for using Subversion FS APIs?
>
>
>
> Someone answered back:
>
> Subversion's FSFS store is meant to be used by the subversion server. While
> it might be useable in other scenarios, whatever sits on top of it will
> likely have to act much like a subversion server when interacting with it.
> Subversion differentiates between client workspaces and the server storage
> space. If you are going to leverage subversion components, your application
> needs to realize that these two spaces are not the same within a subversion
> architecture, and therefore should not be the same within your solution that
> uses their components.
>
> Why not just embed a subversion client into the place you desire and then go
> from there? The user workspace will still be "the subversion user workspace"
> and the server side will be the server side. In fact, check out tortise SVN
> (or other desktop integrations of subversion). You might not even need to
> write anything.
>
> I asked again with more context for the project:
>
> SVN Client API will have performance penalty since it will go through other
> layers such as user authentications, authorizations, transport etc. which
> are not needed for us. Subversion server side API will bypass those calls. I
> wonder which API mod_dav_svn used.
>
> Regards,
>
> Ren
>
>
>

-- 
Philip Martin
WANdisco