Sameer Parwani

On a recent multi person project, we’ve used a subversion client to directly pull the latest project files into the web directory. We do so because its a complicated environment that we have not yet created individual sandboxes for. To test a change, the code must be committed to subversion and then we execute “svn export” on the webserver to pull the latest files from our subversion repository directly to the web directory. The only downside seemed like we were going to have a crazy number of revisions. But we’ve also run into one other problem: APC.

APC is the Alternate PHP Cache which caches bytecode for compiled PHP files. Every time PHP tries to run (or even includes) a PHP file, the file must first be compiled into bytecode. APC goes ahead and caches the bytecode which can save a tremendous amount of time for the execution of your PHP scripts. APC invalidates the cached bytecode when the source file is updated/deleted.

However, we have found that after updating our web directory via the subversion client, occasionally APC does not realize the file has been updated and will not invalidate the cache entry. When the problem first reared its head, it took hours to figure out what was going on because any change I made did not want to show up unless i restarted Apache.

I’m not quite sure why APC failed to invalidate the cache for the target file but I would venture to guess that its because subversion will transfer a file and maintain its last modified time. If the last modified time happens to be in the past, maybe APC ignores it? Especially if the filesize did not change?

To solve the problem, we now update the last modified time of each file after it is pulled from subversion with the unix command “touch”.

#!/bin/sh
BASEPATH=/path/to/webroot

svn export http://svnurl/ $BASEPATH --force --username user --password pwd

find $BASEPATH | xargs touch

APC then will invalidate its cache for ALL the PHP files in your BASEPATH. That happens to be unideal behavior as you would like it to only invalidate the cache for the updated files. But, as long as your subversion script is not run too often, you will still get a significant performance gain.

If anyone else runs into a similar problem and wants to find the perfect solution I would suggest:

a) pull the lasted subversion files into a temp directory
b) run rsync on dry run mode (-n) to output what files need to be updated (rsync -avn /tmp/webroot /path/to/webroot) and save the list of files somewhere
c) copy /tmp/webroot to /path/to/webroot
d) “touch” the .php files that were saved in step b