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:/// 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
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
Received on 2015-11-08 18:28:34 CET