[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: Stefan Sperling <stsp_at_elego.de>
Date: Thu, 24 Mar 2011 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).
Received on 2011-03-24 12:38:47 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.