How to Create and Store a Symfony Project in Subversion
How to Create and Store a Symfony Project in Subversion¶
This entry is specifically about Subversion, and based on principles found in How to Create and Store a Symfony Project in Git.
Once you've read through Creating Pages in Symfony and become familiar with using Symfony, you'll no-doubt be ready to start your own project. The preferred method to manage Symfony 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 Symfony 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:
1 2 3 4
myproject/ branches/ tags/ trunk/
Initial Project Setup¶
To get started, you'll need to download Symfony and get the basic Subversion setup:
Download the Symfony Standard Edition with or without vendors.
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.
Checkout the Subversion repository that will host this project. Suppose it is hosted on Google code and called
$ svn checkout http://myproject.googlecode.com/svn/trunk myproject
Copy the Symfony project files in the Subversion folder:
$ mv Symfony/* myproject/
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:ignoreproperty, so that specific files can be ignored.
1 2 3 4 5 6 7 8 9 10 11 12
$ 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.yml" 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.yml, app/cache/*, app/logs/*, web/bundles)"
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"
parameters.ymlfile is ignored by svn (see above) so that machine-specific settings like database passwords aren't committed. By creating the
parameters.yml.distfile, new developers can quickly clone the project, copy this file to
parameters.yml, customize it, and start developing.
Finally, download all of the third-party vendor libraries by executing Composer. For details, see Updating Vendors.
If you rely on any "dev" versions, then Git may be used to install those libraries, since there is no archive available for download.
At this point, you have a fully-functional Symfony 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 Symfony chapter to learn more about how to configure and develop inside your application.
The Symfony 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
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
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 composer.phar install
"downloader" binary. This
composer.phar file is from a library called
Composer and you can read more about installing it in the Installation
composer.phar file reads from the
composer.json file at the root
of your project. This is an JSON-formatted file, which holds a list of each
of the external packages you need, the version to be downloaded and more.
composer.phar file also reads from a
composer.lock file, which
allows you to pin each library to an exact version. In fact, if a
file exists, the versions inside will override those in
To upgrade your libraries to new versions, run
php composer.phar update.
If you want to add a new package to your application, run the composer
$ php composer.phar require doctrine/doctrine-fixtures-bundle
To learn more about Composer, see GetComposer.org:
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
vendor/. But since all the information needed to download these
files is saved in
composer.lock (which are stored
in the repository), any other developer can use the project, run
php composer.phar 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, they should run the
php composer.phar install
script to ensure that all of the needed vendor libraries are downloaded.
Subversion Hosting 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 is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License .