Revive Adserver In A Version Control Environment

[impdesigns]

I've successfully upgraded an OpenX install and have set up Revive Adserver in a git version controlled environment. I think I know the answer to my question, but would like to get confirmation from the community and/or developers. 

 

I'm trying to identify the directories that would need to exist independent of the version control, i.e., areas that the app uses to write and store data. It appears I'd need to exclude: 

 

www/images 

var/

 

It appears that the app writes a lot of cached/compiled data to var/ but I may only need to exclude specific directories such as var/templates and var/cache

 

I also noticed that the plugins and www/admin/plugins directory are listed as directories to set to 777 when upgrading. Should they also be excluded from version control?

 

Thanks in advance

[Richard Foley]

Good candidates for the .gitignore file:

 

  var/ appears to be a lot like tmp/ everywhere else (on the os)

 

For images, you might want to include the core contents of the folder, but exclude the images:

 

  www/images/*jpg

  www/images/*png

 

I'd be inclined to keep the plugins under git.

[impdesigns]

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. 

 

Anyway, hope this helps someone some day… 

[andrewatfornax]

There's actually a .gitignore file in GitHub...

https://github.com/revive-adserver/revive-adserver/blob/master/.gitignore