By the way, typing "memcached" into the search box at http://svn.haxx.se/
turns up lots of information, including people reporting
performance measurements.
Thanks for the reminder. There is much more on getting it to work under various linux variants than anyone attempting to do it on windows. And no-one there seems to have an easy time getting it working either. Why am I trying on windows? It is what I have to work with.

I'd really like re-compiling everything to be a last resort! I'm not sure that it should be necessary and if I tried it and it still didn't work I couldn't be sure that I hadn't made a mistake somewhere.

 It would also be great if I could end this with step-by-step instructions to help the next googler / svn.haxx.se user achieve the same thing.

Thank you,

Matthew




On Fri, Feb 26, 2010 at 9:09 PM, Matthew Beets <mbeets@gmail.com> wrote:
Thanks for the responses so far.
 
Not to discourage you from trying, but the others that have done the
same did not see any tangible benefits.  Most of these users were
already using pretty fast disk systems for their repositories, so
perhaps if yours are on a single spindle or something and you have a
lot of RAM for the cache you might see different.
The tests that I've seen seem to have been done using some serious hardware. My situation is much more modest with a SVN repository on a disk shared by a bunch of other processes.

They were never specifically compiled with our without memcached.  The
binaries are including the latest (as of a month ago) version of httpd
and apr and using the standard Apache build process that it provides.
If that builds memcache support on Windows then they include them.  If
you have to retrieve some special package or use special compile
options then it does not and never has.

I should have added that we provide the source code and build scripts
that go into each release alongside the download.  So feel free to
download the source zip and look at the scripts etc.

I have downloaded the source for the Collabnet Subversion server. Comments at this website: http://github.com/apache/apr-util say that:

To give a brief overview, the primary core
   subsystems of APR-util 1.3 include the following:

     ...
     MemCache interface
     ...

Which would make me believe that if you are using their standard build for APR-util that it would have memcache support rolled in. A search within the libaprutil-1.dll (version 1.3.9) that comes within the collab install does show up references to the following functions: 

apr_memcache_add
apr_memcache_add_multget_key
apr_memcache_add_server

Again this feels like it has had support for it compiled in. I can't find anything specific that says you must do blah to compile support for it on windows.

Thanks,

Matthew



On Fri, Feb 26, 2010 at 5:58 PM, Mark Phippard <markphip@gmail.com> wrote:
On Fri, Feb 26, 2010 at 7:57 AM, Mark Phippard <markphip@gmail.com> wrote:
> On Fri, Feb 26, 2010 at 7:54 AM, Stefan Sperling <stsp@elego.de> wrote:
>> On Fri, Feb 26, 2010 at 05:44:38PM +0200, Matthew Beets wrote:
>>> Now when I try to checkout my empty test repository ( using "svn checkout
>>> svn://localhost/test C:\svntestcheckout" )  I get the message:
>>>
>>> svn: apr memcache library not available
>>
>> Sounds like the APR library shiipping with the collab.net svn binaries
>> has not been compiled with support for memcached.
>>
>> They certainly used to, but maybe this has changed?
>> See http://svn.haxx.se/users/archive-2009-06/0676.shtml
>
> They were never specifically compiled with our without memcached.  The
> binaries are including the latest (as of a month ago) version of httpd
> and apr and using the standard Apache build process that it provides.
> If that builds memcache support on Windows then they include them.  If
> you have to retrieve some special package or use special compile
> options then it does not and never has.

I should have added that we provide the source code and build scripts
that go into each release alongside the download.  So feel free to
download the source zip and look at the scripts etc.


--
Thanks

Mark Phippard
http://markphip.blogspot.com/