stefan2_at_apache.org wrote on Mon, Nov 26, 2012 at 00:21:26 -0000:
> Author: stefan2
> Date: Mon Nov 26 00:21:26 2012
> New Revision: 1413451
>
> URL: http://svn.apache.org/viewvc?rev=1413451&view=rev
> Log:
> On the cache-server branch.
>
> * BRANCH-README: add
>
> Added:
> subversion/branches/cache-server/BRANCH-README
>
> Added: subversion/branches/cache-server/BRANCH-README
> URL: http://svn.apache.org/viewvc/subversion/branches/cache-server/BRANCH-README?rev=1413451&view=auto
> ==============================================================================
> --- subversion/branches/cache-server/BRANCH-README (added)
> +++ subversion/branches/cache-server/BRANCH-README Mon Nov 26 00:21:26 2012
> @@ -0,0 +1,109 @@
> +Goal
> +====
> +
> +Provide a stand-alone executable that will provide a svn_cache__t
> +implementation based on a single shared memory. The core data
> +structure and access logic can be taken from / shared with today's
> +membuffer cache. The latter shall remain available as it is now.
memcached solves the problem you're stating above, and it's an
independent third-party project. Your solution is specific to
Subversion (it's in libsvn_subr and is not in the public API). If
you're solving the same problem memcached does, why does your solution
need to be specific to svn? Should it be a standalone tool that
Subversion interfaces to as an optional dependency, and any other
memcached consumer can switch to too?
I don't mean to discourage you from doing this work; I just wonder
whether the non-public parts of libsvn_subr is the right place for
it to live in.
Received on 2012-12-17 11:26:33 CET