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

Re: using libsvn_fs standalone

From: <cmpilato_at_collab.net>
Date: 2003-06-13 17:43:09 CEST

"Tim Hawkins" <tim@timhawkins.co.uk> writes:

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

I don't know if any timings have been for this. Great improvements
have been made over time with this (most notably in the way of the
brane's delta combiner and ghudson's skip-delta storage scheme) -- all
I can say is, "give it a shot and see whatcha think."

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

File versions aren't "live" until the transaction in which they were
created is committed (using svn_fs_commit_txn()). So you can delay
the commit of the transaction indefinitely. But understand that the
Subversion filesystem has logic for trying to prevent people from
changing things that, from a version control standpoint, they
shouldn't be allowed to change as a result of being "out of date".
This might cause you some problems. For example, if you:

  1. make a txn A based on HEAD
  2. change file 'code.c', but don't commit txn A
  3. make a new txn B, again based on HEAD (you can't base a
      txn on another txn)
  4. change the file 'code.c' again, but don't commit txn B
  5. commit txn A
  6. commit txn B

I would expect step 6 to fail as a safety measure because 'code.c' was
modified between HEAD and the commit of txn B (specifically, by the
commit of txn A).

Is this what you're asking about?

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 13 17:44:18 2003

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

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