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...

Reply via email to