Return-Path: X-Original-To: apmail-subversion-users-archive@minotaur.apache.org Delivered-To: apmail-subversion-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 8D28E181D1 for ; Fri, 6 Nov 2015 18:43:57 +0000 (UTC) Received: (qmail 43590 invoked by uid 500); 6 Nov 2015 18:43:56 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 43552 invoked by uid 500); 6 Nov 2015 18:43:56 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 43532 invoked by uid 99); 6 Nov 2015 18:43:56 -0000 Received: from Unknown (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 Nov 2015 18:43:56 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 1A3C4180E13 for ; Fri, 6 Nov 2015 18:43:56 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.148 X-Spam-Level: *** X-Spam-Status: No, score=3.148 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, HTML_MESSAGE=3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-us-east.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id 1U597MuNGKag for ; Fri, 6 Nov 2015 18:43:55 +0000 (UTC) Received: from mail-io0-f182.google.com (mail-io0-f182.google.com [209.85.223.182]) by mx1-us-east.apache.org (ASF Mail Server at mx1-us-east.apache.org) with ESMTPS id CEC16429AA for ; Fri, 6 Nov 2015 18:43:54 +0000 (UTC) Received: by ioc74 with SMTP id 74so65278235ioc.2 for ; Fri, 06 Nov 2015 10:43:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=PpGvV16KsFQ9bEUzNEdKBRXpNgaPhPhFEmn/jzBiD94=; b=Uf57SGbOx1NjW6YwMOJtn/SfVdDxfPuUwW/wBL2bBiisr7laj0iqejpsiedVS0XpA7 MeBwIQbSfTW6aQDZDVPmAanEm1BGUX9NaR7pipFfuanV7/QCZ32cDjlH6DNYX/N9n+g+ uyksxGwHdLY0f53P5W1oCPCtZw9eHlah1eP5hzQA5AOaDvjR9XPWCRYv6rCRByYahABs gqYqqwaYgkVHt1JgST22u7uFE4N3INJubeA/eIHJqLywpXzmgtQ03C6cS84YnKzX6hhy rpEP0cJUPlFYQB0QJPgYqP7k3YrBQA+cQOscip+uhJE5Vsi2IYmUoGlrqqheRfe5T5kl 14gA== X-Received: by 10.107.135.65 with SMTP id j62mr4310421iod.47.1446835428107; Fri, 06 Nov 2015 10:43:48 -0800 (PST) Received: from anninadesktop (UNVLON5554W-LP130-02-1279557054.dsl.bell.ca. [76.68.125.190]) by smtp.gmail.com with ESMTPSA id bf8sm113724igb.1.2015.11.06.10.43.47 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 06 Nov 2015 10:43:47 -0800 (PST) From: "Ren Wang" To: Subject: Subversion C API Date: Fri, 6 Nov 2015 13:44:13 -0500 Message-ID: <001801d118c3$223716a0$66a543e0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01D11899.39610EA0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdEYwn/WGi3kt18zTGqdhqNK0PbncQ== Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_0019_01D11899.39610EA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 ------=_NextPart_000_0019_01D11899.39610EA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 <= /p>

------=_NextPart_000_0019_01D11899.39610EA0--