And finally:
rm -vf $LIST

Hmm… looking at the respective path I can see that the command is not lying and that file fsfs.conf is indeed not present. I could find a file fs-type but not fsfs.conf. So my only assumption was that this is an older repository created with an older svn version than the one we were running currently. Checking the existing svn version I got:
svn --version
svn, version 1.6.11 (r934486)
compiled Apr 20 2010, 00:24:22
and the fact that this repo was very old (~2009) made my assumption sound correct. Ok, now what? Well in this situation my first thought was to use the svnadmin upgrade command; from the manual it looked like this is what I needed to fix this issue:

“svnadmin help upgrade
upgrade: usage: svnadmin upgrade REPOS_PATH

Upgrade the repository located at REPOS_PATH to the latest supported
schema version.

This functionality is provided as a convenience for repository
administrators who wish to make use of new Subversion functionality
without having to undertake a potentially costly full repository dump
and load operation.  As such, the upgrade performs only the minimum
amount of work needed to accomplish this while still maintaining the
integrity of the repository.  It does not guarantee the most optimized
repository state as a dump and subsequent load would.”

After I’ve made a manual backup archive of the repo (a simple tar.gz of the repo folder) I ran the upgrade command sure this is going to fix my issue:
svnadmin upgrade /svn/repo/
and after it completed, I verified that svn was still working as expected and checked for the fsfs.conf file. But that was not created… Hmm… Let’s try the hotcopy command anyway:
svnadmin hotcopy --clean-logs /svn/repo/ /tmp/repo/
svnadmin: Can't open file '/svn/repo/db/fsfs.conf': No such file or directory
the exact same error.

Trying to understand what the fsfs.conf file contains I just created a new repository to see if it gets created. Indeed my v1.6.11 of svn created the file for a new repo, and after copying it to the location of my existing repository (as it was basically just an empty file) my issue was fixed and the hotcopy command started working. Here is the content of the file as created by my svn version, that I copied in the older repo to fix this problem:

cat fsfs.conf
### This file controls the configuration of the FSFS filesystem.

[memcached-servers]
### These options name memcached servers used to cache internal FSFS
### data.  See http://www.danga.com/memcached/ for more information on
### memcached.  To use memcached with FSFS, run one or more memcached
### servers, and specify each of them as an option like so:
# first-server = 127.0.0.1:11211
# remote-memcached = mymemcached.corp.example.com:11212
### The option name is ignored; the value is of the form HOST:PORT.
### memcached servers can be shared between multiple repositories;
### however, if you do this, you *must* ensure that repositories have
### distinct UUIDs and paths, or else cached data from one repository
### might be used by another accidentally.  Note also that memcached has
### no authentication for reads or writes, so you must ensure that your
### memcached servers are only accessible by trusted users.

[caches]
### When a cache-related error occurs, normally Subversion ignores it
### and continues, logging an error if the server is appropriately
### configured (and ignoring it with file:// access).  To make
### Subversion never ignore cache errors, uncomment this line.
# fail-stop = true

[rep-sharing]
### To conserve space, the filesystem can optionally avoid storing
### duplicate representations.  This comes at a slight cost in performace,
### as maintaining a database of shared representations can increase
### commit times.  The space savings are dependent upon the size of the
### repository, the number of objects it contains and the amount of
### duplication between them, usually a function of the branching and
### merging process.
###
### The following parameter enables rep-sharing in the repository.  It can
### be switched on and off at will, but for best space-saving results
### should be enabled consistently over the life of the repository.
# enable-rep-sharing = false

Hopefully this will help others seeing the same issue I was experiencing.

I’ll assume that you have installed apc already, if this is not the case this will probably be something as simple as running
pecl install apc
or downloading the archive from pecl and running:
phpize; ./configure; make; make install

The APC extension needs to be enabled either in php.ini or in one included file with a line like this:
extension=apc.so
there are many other parameters that apc can be fine tuned (see the official doc for more info), but without any other change, just with this line apc will be enabled on all the vhosts on the server.

Disabling some vhosts from using APC
- if we want to disable APC for a particular vhost we just have to add to the vhost config or to .htaccess:
php_flag apc.cache_by_default Off

Enabling APC only on some vhosts
- if we want to have APC disabled by default globally we will have in php.ini:

extension=apc.so
[apc]
apc.cache_by_default=0 # disable by default
... other apc settings...

and we will enable APC for the particular vhost config or using .htaccess using:
php_flag apc.cache_by_default On

Hopefully you found this post useful and this will give you a reason to use APC with more confidence knowing that you have the granularity to disable/enable it as needed in a shared environment.

The problem is on the copied site that is on a new domain as we cannot login and go to the admin section because it redirect back to the source/original site. What we need is either disable the securepages module or update the domains. To do this, you need to access your database (ex: phpmyadmin, etc), go to variable table, and search for securepages configurations.

If you want to disable the module change:
securepages_enable s:1:"1";
to
securepages_enable s:1:"0";

Or if you want to update the domain change:
securepages_basepath s:30:"http://www.domain.com";
securepages_basepath_ssl s:31:"https://www.domain.com";
to
securepages_basepath s:30:"http://www.newdomain.com";
securepages_basepath_ssl s:31:"https://www.newdomain.com";

After making the above changes don’t forget to run the update.php (http://www.newdomain.com/update.php)

If you want to uninstall the module, try removing the securepages directory and run update.php.

What we did to eliminate this issue and be able to update the site automatically was to create a copy of the original core modules (located in /modules), add our custom functionality, and put the modified copy into ‘contributed’ modules directory (/sites/all/modules). Drupal read the modules found on /sites/all/modules first and ignore the same copy (original) found on /modules. Also, may want to change the module info or the package name to separate the modified modules from the original ones – ex: modified_core, custom, etc. In the case that Drupal reads both of them, you can just disable the other one.

Here’s our policy on working with Drupal modules:
– contributed or community modules at /sites/all/modules
– custom made modules at /sites/all/modules/custom
– modified core modules at /sites/all/modules/core_modified

Hope this helps.

Ok, I got the error above when I performed Drupal CVS update on our Debian server (newly installed CVS 1.12.13). The same command works on other server with older CVS installation. The issue is the reference to local cvs directory where I used absolute path (-d /path/drupalsite/), which is a bug (security hole on client side) – it was fixed on newer CVS version to use relative path.

Drupal Checkout Command:
cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal co -r DRUPAL-6-15 -d /path/drupalsite/ drupal

Use of Relative Path (sample)
cd /path
cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal co -r DRUPAL-6-15 -d drupalsite drupal

In order to enable error reporting for your php script or application include inside your code the following lines:
error_reporting(E_ALL);
ini_set("display_errors", 1);
and this will result in displaying in the browser any errors your application might have.

ps: once you are done with this and fixed the issue, don’t forget to remove the error reporting lines, as we don’t want our users/clients to see errors in the browser in case something went wrong.

location /images {
	valid_referers   none  blocked  server_names  mydomain.com www.mydomain.com;
	if ($invalid_referer) {
		return   403;
	}
	... else serve the content
}

This works fine in this simple case; but what if we need to list more sub-domains? like images.mydomain.com an static.mydomain.com, etc? It would be nice to be able to use a regexp for this, right? Fortunately nginx has support for this and this can be done using a valid_referers line like:
valid_referers none blocked server_names ~(mydomain.com)

And this will match all the subdomains *.mydomain.com. Going even further you might want to allow google as a referrer for you content. Still google has so many subdomains and even different domains (like google.com, google.de, etc.) For this we could add ~(google.) and have our final configuration look like this:

location /images {
	valid_referers   none  blocked  server_names  ~(mydomain.com|google.);
	if ($invalid_referer) {
		return   403;
	}
	... else serve the content
}

This simple example shows how powerful the configuration of nginx is and how easy it is to do things that are rather impossible with other similar softwares.

If the remote ssh server is not running on the default ssh port (tcp 22) then this needs a little tweaking to get it working. Normally I was expecting that adding a custom entry for the svn server in the /etc/ssh/ssh_config file with the appropriate port would make this work on the fly without changing the command line; or if not, adding the ssh port in ‘telnet like’ way: server:port would make a difference. Still none of those worked and in order to get this working I had to dig into the subversion documentation on how we can define a special tunnel.

We can define a new tunnel in the svn configuration file (.subversion/config):
[tunnels]
sshtunnel = ssh -p <port>

And after this we can use svn as usual but with a url like svn+sshtunnel:// :
svn co svn+sshtunnel://user@server/repo .