Subscribe to our feed

Symfony Experts

Symfony Experts
If you have an urgent question for a symfony-related issue, this is the place to ask.


Stack Overflow

The old fashioned way


December 10, 2008 – 8:05pm Starting a new symfony project: Tips for sanity and bliss with SVN

There is something gratifying about starting a new project. You get to start fresh and it may be the only time during the project lifespan where everything is perfect.

Over time I’ve learned a few tricks that personally make my project environment a pleasure to work with. Here are the requirements:

  • The project should be use SCM for some type of version control, we’ll use SVN here.
  • The symfony source code should use svn:externals so we can pull updates to the symfony base.
  • We must ignore any files that are unnecessary for version control, like cache/ or log/, and we should also ignore any auto-generated files. (Read the sidebar on Eric Sink’s page on repositories to find out why, but it comes down to a matter of preference.)
  • We should make sure to tag any version of the project before deploying to the production server. That means no symfony sync production here!
  • The site should have a friendly local url we can use while we test, somthing like http://myapp.local/ or http://myapp.trunk/.

Alright, let’s get started. First thing I’m going to create a space in my local ~/Sites folder.

mkdir ~/Sites/myapp
cd ~/Sites/myapp/
mkdir trunk branches tags

I create these three folders inside my project folder to ease building on multiple branches of the project at one time. Often times I’ll end up with a live version of the site, and then I’ll start on a big revision which is unstable, and if there is ever a bug fix required on the live site, I have no way to easily deploy it. So, by creating this directory structure, it both accommodates working on multiple versions of the same site and it also encourages me to follow these principles while I am working. If the live site needs a fix, I can download that tag, create the fix, and then retag it and deploy it back to the live site without messing up my current development branch, or accidentally deploying new features that aren’t ready for prime time.

Since I don’t actually have the latest version of symfony on my computer, I want to go ahead and create my new respository, check it out into ~/Sites/myapp/trunk and then add the svn:externals property to lib/vendory/symfony and pull down the code that way.

Here is how I have to create a new svn repository on my computer. Note your path to your svn repository will be different, and you may not have to use “sudo” if you have write permissions to the svn path. Also note that some symfony docs will show an “http:” svn url here, although the svn book says that http is not allowed for svnadmin create commands.

sudo svnadmin create /usr/local/svn/myapp

Another thing I have to do as a result of my svn set up is make sure this new repository has write permissions for my web user, since I access my repository over a url like http://localhost/svn/ instead of a file:/// path. (See this post about setting up your OS X machine with svn over http).

sudo chown -R www:www /usr/local/svn/myapp

Now it’s time to create the default directory structure.

svn mkdir -m "init directory structure" http://localhost/svn/myapp/trunk http://localhost/svn/myapp/branches http://localhost/svn/myapp/tags

And lets check in our pitifully empty project into svn:

svn co http://localhost/svn/myapp/trunk trunk

Now lets setup svn externals so that we can pull down the latest version of the symfony framework.

cd ~/Sites/myapp/trunk
svn mkdir lib
svn mkdir lib/vendor
svn propedit svn:externals lib/vendor

After that last command enter:


Then, check in this new externals definition and give yourself an update.

svn ci -m "adding externals to lib/vendor for symfony 1.2.0"
svn update lib/vendor

Now, inside lib/vendor/symfony you should have all of the symfony framework files. Sweet. We can check the configuration with these commands within our trunk/ directory.

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

If all goes well you’ll see the symfony version number printed out, in this case:symfony version 1.2.0 (/Users/smeves/Sites/gyro/dam/trunk/lib/vendor/symfony/lib)

It’s now time to actually create the app structure.

php lib/vendor/symfony/data/bin/symfony generate:project myapp

This will create a bunch of standard symfony directories. Let’s also create our default app.

./symfony generate:app --escaping-strategy=on --csrf-secret=mysecret frontend

One more task before we load this all into svn is to update your local configuration to make it more portable. Open up config/ProjectConfiguration.class.php and make the require_once line relative, using the path of the file itself as a starting point.

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

Now we should check all of these new files into svn and ignore some of the files we don’t want in svn, like whatever is inside log/ and cache/. Let’s also go ahead and make sure log/ and cache/ are writable.

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 "creating project structure"

Enter * after each of the two propedit commands.

There will be a few other auto-generated files that we can ignore, but we don’t have them yet since we haven’t created our model. Let’s switch gears for a second and set up our local apache environment so we can serve up our new project with a friendly url. Since I am on a mac and like to use Textmate as my text editor, I’m going to use it to modify my apache’s configuration file. This may be different for you, but the goal is to add a new virtual host.

mate /etc/apache2/users/smeves.conf

And add the following to the file. Your paths will be different.

<VirtualHost *:80>
	ServerName dam.trunk
	DocumentRoot /Users/smeves/Sites/myapp/trunk/web
	DirectoryIndex index.php
  <Directory "/Users/smeves/Sites/myapp/web">
    AllowOverride All
    Allow from All
  Alias /sf /Users/smeves/Sites/myapp/trunk/lib/vendor/symfony/data/web/sf
  <Directory "/Users/smeves/Sites/myapp/trunk/lib/vendor/symfony/data/web/sf">
    AllowOverride All
    Allow from All

I also need to add this new server name, myapp.trunk, to my local hosts file so my computer knows not to go out on the internet looking for a website with the actual domain myapp.trunk.

mate /etc/hosts

and enter:   myapp.trunk

Save those files and restart apache.

sudo apachectl graceful

Now, lets test to see if everything worked. Load up http://myapp.trunk/. You should see the “Symfony Project Created” screen. If not, go back on check your configuration. Otherwise, we are ready to actually start coding.

Once you create a model, it is a good idea to ignore the auto-generated files from svn too. I usually forget to do this until after I generate the model, so this is what I do:

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

After the last two commands, enter * to ignore all of the files inside those directories.

So, with that, we are done with the set up. From here on out, you should just remember to check in your changes, and when you are ready for a deployment, create a new tag, and then check that tag out on the server. Here is a good reference for that from an earlier post.

svn copy file:///path/to/repos/trunk file:///path/to/repos/tags/1.0release -m "tagging version 1.0 release"

A lot of these tips and techniques were learned from Day 1 in the Jobeet tutorial and Dave Dash’s post on symfony and subversion. Good luck with your new project!

Posted by in  Web Development   |  

9 Responses to Starting a new symfony project: Tips for sanity and bliss with SVN

  1. cpr says:

    How do you deal with plugins? Do you not add them to subversion at all?

  2. Pingback: using svn for development in symfony | Connecting the dots...

  3. tsmTom says:

    @cpr: I tend to use svn:externals for including plugins instead of the native symfony plugin install feature. I find it a lot easier/cleaner this way. The only drawback is that often, a plugin isn’t available in the symfony svn repo, or at least the latest versions isn’t.

  4. Pingback: Lazzaro Leonardo Blog » PHP Symfony kick start

  5. I use svn:externals for plugins

  6. Scott Meves says:

    For a while I used svn:externals for plugins, but I’ve been burned a few times from a harmless “svn up” that pulled down a newer version of a plugin that was incompatible with the existing app. So, now I only use svn:externals for plugins if the plugin has been tagged, and never use it when the only version in svn is the plugin trunk.

  7. Pingback: Symfony project on (bluehost) shared hosting @ GIS and Web Tricks

  8. Vijay says:

    Good Stuff..Actually i wanted build an apllication using symfony and what are the things i need to consider before starting the project …like regarding ORM,deployment,Plugins etc

  9. Pingback: using svn for development in symfony | Evernotes...