How can I convert an existing website, deployed to multiple servers, to be SVN managed and not blow away user files?

Question

I have an existing website that uses the same code base, but is deployed in a number of different configurations on different servers. Each configuration has a set of users, and they can upload personal files. The files are stored in an "uploaded files" directory on each server, and this directory is stuck in right next to the code that runs the site.

I am trying to bring the codebase into Subversion so we can manage things better, and also use SVN to make deployment easier as well, however, on each server the user files will be different. I understand that the best way to handle this would be to store the user files elsewhere, but at this point, that isn't an option.

So, with that in mind, how can I use Subversion in light of this situation?

Answer 1

Just don't store that folder in your repository, eg. never check that folder in. I don't really see a problem here...

Answer 2

Don't check it in that way you can't overwrite anything. For config.ini files and the like you can store a template version with a different name (ie. config.ini.tmpl) in your repository that won't overwrite the actual file.

Add the folder/files to your svn ignore so you don't check them in by accident.

It is also good practice to export to a new folder then do a quick mv or httpd.conf edit, apache restart to change to the new version all at once. If you do that you can copy the upload files and/or keep the old version as backup in case something goes screwy with your deployment or the new version of the code.

Answer 3

Here is the method I eventually used:

I checked everything in on the development server, including the user files there. This allows for the entire dev server to be checked out so everyone has the same batch of code.

Then, for servers other than the dev server, I copy away the user files that were on the server, do a clean checkout, "un-check out" the directory with the user files by updating that directory to revision and removing it from the Working copy, and then copying the original files from that server back in.

This seems to work well, and while it isn't ideal, it hasn't caused any problems yet because Subversion just sees those files as unversioned.

Also, for config files, we did go with appending .template to those small number of files.