How to Create and store a Symfony2 Project in Subversion

Edit this page

Warning: You are browsing the documentation for Symfony 2.0, which is no longer maintained.

Read the updated version of this page for Symfony 6.1 (the current stable version).

How to Create and store a Symfony2 Project in Subversion


This entry is specifically about Subversion, and based on principles found in How to Create and store a Symfony2 Project in git.

Once you've read through Creating Pages in Symfony2 and become familiar with using Symfony, you'll no-doubt be ready to start your own project. The preferred method to manage Symfony2 projects is using git but some prefer to use Subversion which is totally fine!. In this cookbook article, you'll learn how to manage your project using svn in a similar manner you would do with git.


This is a method to tracking your Symfony2 project in a Subversion repository. There are several ways to do and this one is simply one that works.

The Subversion Repository

For this article it's assumed that your repository layout follows the widespread standard structure:



Most subversion hosting should follow this standard practice. This is the recommended layout in Version Control with Subversion and the layout used by most free hosting (see How to Create and store a Symfony2 Project in Subversion).

Initial Project Setup

To get started, you'll need to download Symfony2 and get the basic Subversion setup:

  1. Download the Symfony2 Standard Edition with or without vendors.
  2. Unzip/untar the distribution. It will create a folder called Symfony with your new project structure, config files, etc. Rename it to whatever you like.
  3. Checkout the Subversion repository that will host this project. Let's say it is hosted on Google code and called myproject:

    $ svn checkout myproject
  4. Copy the Symfony2 project files in the subversion folder:

    $ mv Symfony/* myproject/
  5. Let's now set the ignore rules. Not everything should be stored in your subversion repository. Some files (like the cache) are generated and others (like the database configuration) are meant to be customized on each machine. This makes use of the svn:ignore property, so that specific files can be ignored.

    $ cd myproject/
    $ svn add --depth=empty app app/cache app/logs app/config web
    $ svn propset svn:ignore "vendor" .
    $ svn propset svn:ignore "bootstrap*" app/
    $ svn propset svn:ignore "parameters.ini" app/config/
    $ svn propset svn:ignore "*" app/cache/
    $ svn propset svn:ignore "*" app/logs/
    $ svn propset svn:ignore "bundles" web
    $ svn ci -m "commit basic Symfony ignore list (vendor, app/bootstrap*, app/config/parameters.ini, app/cache/*, app/logs/*, web/bundles)"
  6. The rest of the files can now be added and committed to the project:

    $ svn add --force .
    $ svn ci -m "add basic Symfony Standard 2.X.Y"
  7. Copy app/config/parameters.ini to app/config/parameters.ini.dist. The parameters.ini file is ignored by svn (see above) so that machine-specific settings like database passwords aren't committed. By creating the parameters.ini.dist file, new developers can quickly clone the project, copy this file to parameters.ini, customize it, and start developing.
  8. Finally, download all of the third-party vendor libraries:

    $ php bin/vendors install


git has to be installed to run bin/vendors, this is the protocol used to fetch vendor libraries. This only means that git is used as a tool to basically help download the libraries in the vendor/ directory.

At this point, you have a fully-functional Symfony2 project stored in your Subversion repository. The development can start with commits in the Subversion repository.

You can continue to follow along with the Creating Pages in Symfony2 chapter to learn more about how to configure and develop inside your application.


The Symfony2 Standard Edition comes with some example functionality. To remove the sample code, follow the instructions in the "How to remove the AcmeDemoBundle" article.

Managing Vendor Libraries with bin/vendors and deps

How does it work?

Every Symfony project uses a group of third-party "vendor" libraries. One way or another the goal is to download these files into your vendor/ directory and, ideally, to give you some sane way to manage the exact version you need for each.

By default, these libraries are downloaded by running a php bin/vendors install "downloader" script. This script reads from the deps file at the root of your project. This is an ini-formatted script, which holds a list of each of the external libraries you need, the directory each should be downloaded to, and (optionally) the version to be downloaded. The bin/vendors script uses git to downloaded these, solely because these external libraries themselves tend to be stored via git. The bin/vendors script also reads the deps.lock file, which allows you to pin each library to an exact git commit hash.

It's important to realize that these vendor libraries are not actually part of your repository. Instead, they're simply un-tracked files that are downloaded into the vendor/ directory by the bin/vendors script. But since all the information needed to download these files is saved in deps and deps.lock (which are stored) in the repository), any other developer can use the project, run php bin/vendors install, and download the exact same set of vendor libraries. This means that you're controlling exactly what each vendor library looks like, without needing to actually commit them to your repository.

So, whenever a developer uses your project, he/she should run the php bin/vendors install script to ensure that all of the needed vendor libraries are downloaded.

Since Symfony is just a group of third-party libraries and third-party libraries are entirely controlled through deps and deps.lock, upgrading Symfony means simply upgrading each of these files to match their state in the latest Symfony Standard Edition.

Of course, if you've added new entries to deps or deps.lock, be sure to replace only the original parts (i.e. be sure not to also delete any of your custom entries).


There is also a php bin/vendors update command, but this has nothing to do with upgrading your project and you will normally not need to use it. This command is used to freeze the versions of all of your vendor libraries by updating them to the version specified in deps and recording it into the deps.lock file.

Hacking vendor libraries

Sometimes, you want a specific branch, tag, or commit of a library to be downloaded or upgraded. You can set that directly to the deps file :

  • The git option sets the URL of the library. It can use various protocols, like http:// as well as git://.
  • The target option specifies where the repository will live : plain Symfony bundles should go under the vendor/bundles/Acme directory, other third-party libraries usually go to vendor/my-awesome-library-name. The target directory defaults to this last option when not specified.
  • The version option allows you to set a specific revision. You can use a tag
    (version=origin/0.42) or a branch name (refs/remotes/origin/awesome-branch). It defaults to origin/HEAD.

Updating workflow

When you execute the php bin/vendors install, for every library, the script first checks if the install directory exists.

If it does not (and ONLY if it does not), it runs a git clone.

Then, it does a git fetch origin and a git reset --hard the-awesome-version.

This means that the repository will only be cloned once. If you want to perform any change of the git remote, you MUST delete the entire target directory, not only its content.

Subversion hosting solutions

The biggest difference between git and svn is that Subversion needs a central repository to work. You then have several solutions:

  • Self hosting: create your own repository and access it either through the filesystem or the network. To help in this task you can read Version Control with Subversion.
  • Third party hosting: there are a lot of serious free hosting solutions available like GitHub, Google code, SourceForge or Gna. Some of them offer git hosting as well.
This work, including the code samples, is licensed under a Creative Commons BY-SA 3.0 license.