Developer Working Copies

Submitted by freelock on

We generally use Smarty to develop custom sites, and store the site code in Subversion. Here's a quick cheat-sheet on using Subversion with custom sites.

All of these commands should be done as a regular user, the owner of the working copy. See Ubuntu VPS Administration for hints on setting up multiple developer working copies as separate virtual domains.

Initial check out of site

This only needs to be done once, when you're setting up a new working copy. You need to know the Subversion URL to do the initial checkout:
svn co https://repository.yourdomain.com/svn/trunk /var/www/ken

Initial setup of site

We typically store all configuration settings for a particular site in a config.php file in the top directory of the working copy. We typically leave this file out of Subversion, and store a generic copy as config.php-dist.

So the first step is to copy config.php-dist to config.php, and edit the file as appropriate for the site (make sure the include paths are set correctly, as well as database connection settings).

If this copy is to have its own database, we generally store a database dump in a sql/ or config/ directory. MySQL can be set up with a new database, and you can edit config.php to point to the correct place.

Check that the site root matches the Apache virtual host.

Finally, Smarty compiles templates into a templates_c directory. We usually store this directory in Subversion, but never its contents. Verify that the templates_c (or web_files/templates_c) directory is world-writable:
$ chmod o+w templates_c
In some cases, Smarty also caches files. If your site uses this feature, you'll also need to have a writable cache/ directory.

Daily Working process


When working with Subversion working copies, it's best to adopt this general habit:
  • Update your working copy
  • Do your work
  • Commit your changes

Do this every time you work in the code, and it will minimize conflicts between developers.

Update the working copy

To do this, change directories into your working copy, and update:
$ cd /var/www/ken
$ svn up
This collects all the other changes other people have committed to the repository, makes your working copy completely up-to-date.

Do your work

Edit, add, whatever you're going to do in your working copy. Test by visiting your virtual host.

You can see which files you've changed by using:
$ svn st
... to get the status. Use:
$ svn help
to see what else you can do--particularly useful is svn diff.

Commit your changes

When you're done, first add any new files you've been working on. "svn st" will list these files with a "?" in the first column. Do not add your config.php, or any compiled or temporary code (stuff in cache/ or templates_c/):
$ svn add filename

Then you'll do the actual commit to check your changes back into the repository:
$ svn ci /var/www/ken

  • You can leave off the path if you're in your current working copy.
  • You'll be asked to type a commit message to store in the repository. This can be used in the future to roll back to a known point, as well as for a log of changes.
  • Until you do this, nobody else can see your work (other than through your virtual host).