[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Non-file based checkout?

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Fri, 25 Mar 2011 20:49:11 +0200

Stefan Sperling wrote on Thu, Mar 24, 2011 at 12:38:10 +0100:
> On Wed, Mar 23, 2011 at 08:12:57PM -0400, Clifford Yapp wrote:
> > Hi! I'm looking at using the subversion libraries to handle data, and
> > I would like to integrate them into an application for
> > revisioning/managing computer aided design geometry information.
> >
> > Looking over the client API, it seems to assume that a checkout will
> > result in a file in a filesystem path (e.g. a working checkout). Is
> > there a way to request in C the straight-up data from the svn
> > repository without bothering the disk, e.g. checkout svn checkout
> > file://repository/datafile1 and have it returned as a char * array or
> > some other binary form in C? Based on my current understanding I
> > would have to checkout the file in question to a working directory and
> > read it in from there to get it in memory - is that true or is there
> > another, lower level API that doesn't require that step? I have a
> > situation where I have potentially thousands of files, some large and
> > some small, that all need to be individually tracked and then combined
> > into single larger files. It can really kill performance to have to
> > involve the filesystem and write out lots of individual tiny files -
> > ideally I'd like to send information to/from the repository using what
> > would in effect be an in-geometry-storage-file checkout.
> >
> > Any help appreciated - thanks!
>
> Take a look at the svn_client_cat2() function.
> The command-line equivalent is the "svn cat" command.
> The resulting file is read-only, so this is suitable for display
> purposes mosly. You cannot commit changes back to the file, though.
> For committing with the client API, you really need working copy.
> But a working copy of the parent directory is sufficient.
> You could look into using svn_depth_t (the API-equivalent of the
> --depth command-line option) to create working copies that do not
> contain data you don't need.
>
> Another approach would be going beneath the client API (Subversion is
> a stack of layers, with a public API at each layer -- so you're not
> confined to the client API).
> Take a look at the repository access API in svn_ra.h.
> Using that API, it should be possible to write a client that does
> everything in memory. This approach gives you more flexibility.
> But you will need to reimplement parts of what the client library
> implements (a commit editor, for example). To get off the ground quicker
> you could re-use and adjust existing client code (if you're happy with
> the Apache licence).

svnmucc does some of this...
Received on 2011-03-25 18:50:03 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.