RE: using libsvn_fs standalone

Thanks for the comments Greg.

The more I look at libsvn_fs the more it seems to suit my needs.

The environment we are working in pure C++ so there wont be any language
binding problems, I'm going to implement a C++ version of the WVCM binding
and see how far I get with that.

A couple of other quick questions, what is the performance of libsvn_fs as a
file store, we will want to serve content directly out of the ContentStore,
we will have a page cache, but I was wondering what the de-deltafy overhead
would be.

Secondly, and this is going to sound a bit strange, what is the viability of
storing "future" versions of files in the store, such that they only become
current versions once the datetime has been reached, I realise that this may
cause problems as the updates to a file may be applied out of datetime
order. We want to try and achive "scheduling" of content by use of "future"
versions.

-----Original Message-----
From: Greg Stein [mailto:gstein@lyra.org]
Sent: 10 June 2003 22:03
To: Tim Hawkins
Cc: dev@subversion.tigris.org
Subject: Re: using libsvn_fs standalone

On Tue, Jun 10, 2003 at 04:06:23PM +0100, Tim Hawkins wrote:
> Im looking at using libsvn_fs in a standalone mode as a versioned
contentstore for a content management system.
>
> Features I would like to implement over the lib are:
>
> 1. Timetravelled content store, ie view repository at a given date/time.

No problem.

> 2. File/directory meta data, attach additional versioned non-svn metadata
to files/directories.

libsvn_fs records versioned metadata for files and dirs. There is
unversioned metadata on a per-revision basis.

> 3. Add DASL type query support on said metadata.

You would need to create separate indices, which you'd keep up to date each
time you made a change to the FS data. The FS API does not have adhoc query
facilities.

[ for our readers out there: http://www.webdav.org/dasl/ ]

> 4. Add a WVCM style object api over the libary.

Should be possible, I'd think. We already export a subset of the DeltaV
protocol, so I see no reason that a versioning API couldn't also be applied
over the top of the FS.

[ for our readers out there: http://www.webdav.org/deltav/wvcm/ ]

> Questions:
>
> 1. Has anybody had any experience of using libsvn_fs outside of the
subversion project?, and do the panel belive there would be any major
problems with using it in this fashion.

Absolutely. See the SubWiki project at http://subwiki.tigris.org/. It stores
and serves all of the Wiki content directly in/out of an SVN FS repository.
Of course, the neat thing is that you can also use standard SVN to alter the
Wiki content, but SubWiki works just fine without that. It uses the Python
bindings to do its dirty work.

I'm not aware of any other projects directly using the FS, though.

> 2. Is there any usable documentation on the libsvn_fs api?

See svn_fs.h.

> 3. Is any of the above worth attempting to export back to the svn
project?.

I'd be interested in seeing the WVCM stuff. Note that we already have some
work progressing on Java bindings against the various SVN libraries. I don't
have a good handle on their status (I stick with the Python bindings). But
in any case, adding a WVCM layer, bound against the SVN FS or REPOS
libraries would be a fantastic win.

Regarding the DASL stuff, I wouldn't see a lot of utility there until we get
a SQL backend, which can then support the adhoc query facilities provided by
DASL. (altho.. note that DASL *can* limit what is possible to query; you can
arrange it such that DASL only queries the particular subset of items that
you happen to index)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org