Great, it works. Thank you so much! -----Original Message----- From: Philip Martin [mailto:philip.mar...@wandisco.com] Sent: Monday, November 9, 2015 11:08 AM To: Ren Wang <renwang...@gmail.com> Cc: 'Bert Huijben' <b...@qqmail.nl>; users@subversion.apache.org Subject: Re: Subversion C API
The svnlook client uses the FS API to read details of revisions and transactions. Look at the code that implements 'svnlook tree'. "Ren Wang" <renwang...@gmail.com> writes: > Hi Philip, > > Yes, we are looking for the local access and FS API. > > The following are the use cases that we need as the starting point: > > 1) create file and folder > 2) open a directory/root and get its latest files and folders > 3) modify a file, folder > 4) delete file and folder > > Not sure if there is a programming guide. From the test source code > (test_fs), I can figure out use case (1), (3) and (4). But not sure > how to do for use case (2) open a directory/root and get its latest > files and folders. > > > > > -----Original Message----- > From: Philip Martin [mailto:philip.mar...@wandisco.com] > Sent: Monday, November 9, 2015 9:43 AM > To: Ren Wang <renwang...@gmail.com> > Cc: 'Bert Huijben' <b...@qqmail.nl>; users@subversion.apache.org > Subject: 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" <renwang...@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:b...@qqmail.nl] >> Sent: Sunday, November 8, 2015 12:28 PM >> To: 'Ren Wang' <renwang...@gmail.com>; users@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:renwang...@gmail.com] >> Sent: vrijdag 6 november 2015 19:44 >> To: users@subversion.apache.org <mailto:users@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 > -- Philip Martin WANdisco
