RE: Subversion C API
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:/// 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:/// >> 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.
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:/// 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:/// > 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
RE: Subversion C API
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:/// 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:/// 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
RE: Subversion C API
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:/// 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:/// > 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, &
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:/// 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:/// >> 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: >> >>
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:/// 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 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
