I trolled through the svn manuals and some really interesting blog posts and summarizing the steps that I took to put my code base back into control. Its rather unusual that none of the steps below are anything special its just that I hadnt had to work on a situation where I had to work on a feature which might or might not see the daylight of being pushed to production.

So the first thing to do was to create the trunk, branches and tags directory.

$ mkdir ~/websites/secret-project/trunk \
            ~/websites/secret-project/branches \
            ~/websites/secret-project/tags

I now use dreamhost for my svn but you can replace this with any other repo (local or remote) to manage your code. So I would start by creating the initial directory structure in the repo.

$ svn import -m 'Importing the initial directory structure' \
                http://svn.rajatpandit.com/secret-project/trunk \
                http://svn.rajatpandit.com/secret-project/branches \

http://svn.rajatpandit.com/secret-project/tags

Now checking out the empty directory locally to setup the local directories we created locally.

$ svn co http://svn.rajatpandit.com/secret-project/trunk \
               ~/websites/secret-project/trunk

The next step is to ensure that you are always using the most recent version of symfony. I like this feature about svn. You can have multiple directories pointing to multiple repos, that we can always ensure that your project can benefit from the most recent versions. We start that by setting up the lib/symfony and marking that as having an external repo.

$ cd  ~/websites/secret-project/
$ mkdir trunk/lib
$ mkdir trunk/lib/vendor
$ svn propedit svn:externals lib/vendor
symfony http://svn.symfony-project.com/tags/RELEASE_1_2_4/

(1.2.4 being the most recent release at the time of writing this post)
This is a good time to commit this to the svn and get the latest code.

$ svn ci -m 'updating symfony to 1.2.4'
$ svn update lib/vendor

With the most recent codebase available in the vendors directory, now is a good time to do any sanity checks if you fancy.

php lib/vendor/symfony/data/bin/check_configuration.php
php lib/vendor/symfony/data/bin/symfony -V

If all works fine then there is one other configuration change that is required, after which you can start generating the basic stub of your code base. The change is to update the path sfCoreAutoload.class.php so that its picked up relative to where its placed.

require_once dirname(__FILE__).'/../lib/vendor/symfony/lib/autoload/sfCoreAutoload.class.php';

With that done and your basic symfony apps and modules created, you can now update the svn configuration so that you can ignore the cache and logs directory.

$ rm -rf cache/*
$ rm -rf log/*
$ chmod 777 cache
$ chmod 777 log
$ svn add *
$ svn propedit svn:ignore log
$ svn propedit svn:ignore cache
$ svn ci -m "updating the codebase with new apps/modules"

Its also a good idea to ensure that the auto generated files dont make it to the repo, which is clearly a waste as its usually good to generate them on the server after deployment, that way you are usually sure about your configurations and settings.

svn add --non-recursive lib/model
svn add --non-recursive lib/model/om
svn add --non-recursive lib/model/map
svn propedit svn:ignore lib/model/om
svn propedit svn:ignore lib/model/map

You can also do the same for forms and filters any other auto generated file like sql files). Obviously needless to say, you need to commit your files as often as possible and tag after each release.

This post has been heavily adapted from a post on Stereo Interactive which is a blog I usually end up on when I get stuck on symfony problems. Worth reading it as well. This post would usually form as my own pointer when starting on the next project on symfony.