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

Re: Revprop-caching-ng branch ready for review

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Wed, 27 Aug 2014 12:30:18 +0000

Stefan Fuhrmann wrote on Tue, Aug 26, 2014 at 17:04:27 +0200:
> Here the guarantees and limitations of the new implementation:

I haven't had a chance to look at the code (sorry), but two quick
questions based on this summary:

> * No lost updates in revprop file contents even if the
> SVN caches should be stale.
> * A connection (svn_fs_t) will always see at least all
> changes up to and including its own last revprop change.
> * A new connection will always see all changes made
> up to the point the connection got created.
> * On Windows and Unixoids, readers will always see
> the latest data if they are on the same machine as the
> writing process.
> * Depending on OS read cache configuration and if the
> repository is shared between machines, open connections
> *might* no see revprop updates or might see them delayed
> (the open revprop generation file handle may see a stale
> OS file buffer).

Is starvation possible? i.e., is it possible for the delay to be
indefinite (assume the reader fs_t does no write operations)? I assume
the delay would be finite and bounded by a constant if the shared disk's
local file handles have this property.?

Is linearizability guaranteed? i.e., if the repository is load-balanced
across four servers, and I do 'svn ps alpha 1; svn ps beta 2; svn ps
gamma 3; svn pl', is it possible for the last process to see beta
without seeing alpha? (e.g., if each svn process gets load balanced to
a different server.)

Would the last scenario work correctly if the second command had been
an atomic revprop change of property "alpha" with original_value="1"?
(See ORIGINAL_VALUE parameter of svn_client_revprop_set2().)

> * Revprop caching may be inefficient if the repository is
> shared between machines; again depending on OS config.


Received on 2014-08-27 14:30:54 CEST

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.