Thanks for the input… for reference to the community, this is what I ended up with:
First a little background. We use an automated deploy system that utilizes the Ruby on Rails Capistrano gem. It allows us to store a specified number of versions of the site code on the server and, if necessary, roll back a deploy to a previous version. Using this system effectively means defining which 'stuff' should be held in the git repository and which stuff isn't necessary or too dynamic to be tracked. Revive Adserver seems to have been designed to be managed more through manual manipulation of the files via FTP therefore the documentation doesn't really cover our conundrum.
In the Capistrano deploy system, the site account directory contains a releases directory, a shared directory, and a symlink of the site docroot that links to one of the releases. Capistrano manages building symlinks from any of the shared directory contents to the release, so file uploads and other dynamic content gets stored in the shared directory on the server. When the deploy script is run, the script downloads the latest version from the repository to a new, date-coded directory inside the releases directory then resets all the symlinks such that the new release is now connected to the appropriate shared content. It then deletes the oldest release from the releases directory.
Through some careful monitoring of directory contents and a bit of trial and error, we ended up doing the following:
We moved the core contents of www/images to our shared directory and symlinked the whole directory
We symlinked var/cache
We symlinked var/templates_compiled
All of the directories noted were added to our .gitignore file so local changes wouldn't be captured or added to the repository.
This is pretty much the advice shared by Mr. Foley (thank you VERY much by the way), but differs slightly pertaining to the var directory. The var directory also contains the primary config file and some text files that seem to indicate the state of the installation. We felt that they should be part of the repository in case the project is moved to another developer. Having access to those conf files also makes it easy to set the software up in another environment; by simply duplicating a .conf file and find/changing the domain name and database info we've found Revive Adserver is extremely portable from environment to environment. I currently have this installation running locally, in production and in a staging/test environment.
