Mason and I talked a bit about using Subversion to store our web projects. I had originally thought it would be best for each web project to be stored in its own repository (Palmer LTER web is stored elsewhere from CCE LTER web). However, we ultimately decided to stick with the many projects to one repository approach.

This decision comes easily. We already have a repository set up, so there’s no need to go about creating new ones and configuring apache to recognize them. Additionally, none of our projects are on a large enough scale to warrant being separated. Some of the projects may share some common code, and it would easier to merge like components of different projects within a single repository (opposed to distributed repositories). Lastly, it’s easy to migrate projects into seperate repositories should we ever want change to the one-project-per-one-repository approach.

The main issue we discussed is how to store documents: docs, pdfs, imgs, etc… basically files that don’t really need to be versioned. Our solution is to store all such files in a /docs folder that sits at the root level of a given web site. This folder and its contents will not be imported into the repository. When checking out the project, the docs folder will be missing. It will either need to be copied over from another working area, or a symbolic link can be created assuming both working areas are on the same server.

This solution implies that some images may fall under the docs folder. This makes sense, especially if these images are not on the peripheral, but serve a purpose to provide information, be it group photos or mapping grids. Thus, some images embedded into pages’ content will not be versioned.

Some integrated web apps (photo gallery, iforum, etc.) store files at a path deeper than the web root. Any such folders and their contents should also be excluded from the repository. In this case, a README file should be created explaining which folders are missing.

Most of our projects have a config.php file. This file should not be versioned since its settings are usually pertinent only to the local working copy. However, we should commit a config-sample.php file, which is a copy of config.php, but with all sensitive data removed (e.g. database connection settings). A global README file should contain instructions for creating the config.php file:

e.g. Rename config-sample.php to config.php and enter the settings.

A global README file (which rests at the webroot) should also contain information on which folders are being left out of the repository. Each distributed web app can also contain a README file at its root for more in-depth explanation on the information related to that project.

That’s all for now. I’ll add more to this as we make progress loading our projects back into Subversion. The first tests will include the IOD Personnel admin code, and the CCE LTER site.