[tags]symfony, subversion[/tags]
There's some tricks you can do to running a symfony project with subversion:
Ignoring files in cache/ and log/
The first thing you can do (and this is well documented in the askeet tutorial) is ignore files in cache/ and log/. These files are specific to each instance of your app and don't contain anything that needs to be in version control.
Run the following:
cd $SF_ROOT
rm -rf log/* cache/*
svn propedit svn:ignore log
svn propedit svn:ignore cache
svn propedit will bring up a text editor, in both instances you want to save the following:
*
Ignore other auto-generated files
Eric Sink wrote an excellent tutorial on source control. In his chapter on repositories he recommends checking in only hand edited source code. If a property file generates another file, check in the property file, not the auto-generated result. This not only keeps your repository clean, it prevents a lot of unnecessary check-ins.
If you use propel for your ORM layer there are a few files you can ignore using svn propedit svn:ignore {dirname}.
In $SF_ROOT/config we can ignore:
*schema-transformed.xml
These are xml files that propel generates from schema.xml (or schema.yml).
In $SF_ROOT/data/sql we can ignore:
lib.model.schema.sql
plugins.*.sql
sqldb.map
These are created from schema.xml (or schema.yml) as well.
The real savings will come with your model. The propel model creates customizable php classes in lib/model which inherit from auto-generated files in lib/om there are also auto-generated map files in `lib/map'
We can run from $SF_ROOT:
svn propedit svn:ignore lib/model/om
svn propedit svn:ignore lib/model/map
and enter
*
for both properties.
If you've mistakenly checked in some of these files you will need to remove them from your repository via svn delete.
Linking the symfony Library
I prefer to embed the symfony library into each of my symfony apps rather than relying on a shared PEAR library. This lets me run multiple versions of symfony without much fuss. With subversion we can use the svn:externals property to directly link our app with the symfony subversion repository.
At first this sounds like danger, but externals can be linked to specific revisions. However, the symfony team tags their repository with version numbers. To get this to work we need to do 3 things. (UPDATE: See Fabien's comment about using the lib/vendor directory)
Modify
config/config.phpto look for symfony internally. Just open it up and change it so it says this:Run
svn propedit svn:externals libfrom$SF_ROOTand enter:symfony http://svn.symfony-project.com/tags/RELEASE_1_0_2/lib/or whatever version of symfony you want to link to, at the time of this post,
RELEASE_1_0_2is fairly fresh.Run
svn propedit svn:externals datafrom$SF_ROOTand enter:symfony http://svn.symfony-project.com/tags/RELEASE_1_0_2/data/or whatever version of symfony you want to link to, at the time of this post.
Now when you do svn update you'll have the symfony library all linked up. Furthermore this keeps all the developers on the same version of symfony.
Also you may want to start running symfony using ./symfony versus symfony. The former looks at your configuration settings to determine which symfony command to use, the latter is generally linked to your system wide command (which is generally the PEAR installed command).
Linking to symfony Plugins
I have my hands in a number of symfony plugins because I work on a lot of projects which tend to share a lot of similar functionality. Many of the plugins are in early stages of development, so I find it helpful to have them linked from svn as well. This way I can get the benefits of any new functionality and if the occasion should arise, I can contribute any useful changes I make.
To link to the plugins you run svn propedit svn:externals plugins and enter one plugin per line in the following format:
{plugin_name} -r{REVISION} {URL}
For one of my projects I use:
sfPrototypeTooltipPlugin http://svn.symfony-project.com/plugins/sfPrototypeTooltipPlugin
sfGuardPlugin http://svn.symfony-project.com/plugins/sfGuardPlugin
sfZendPlugin http://svn.symfony-project.com/plugins/sfZendPlugin
I've omitted the revision, because I live dangerously and want to use the latest $HEAD.
Great post!
I almost use the same setup except for two small differences:
First, instead of linking to the latest symfony 1.0 tag, I prefer to link to the 1.0 branch:
symfony http://svn.symfony-project.com/branches/1.0
The symfony 1.0 branch is only for bug fixes, so it is always very stable and never introduce new feature or backward incompatible change. Then, whenever you do a svn update, you are sure to have the latest patches. No need to change the link when I release a new 1.0.X release.
The second thing is rather a matter of taste. I create a single svn:externals for symfony in the lib/vendor directory. So my config.php looks like:
Thanks! Yeah I got some of the ideas from another developer who started excluding a lot of the om/* files and then the idea about linking symfony internally from a comment you made somewhere on how it’s done at Sensio
Noticed a typo in the first code block.. we don’t want to svn:ignore the lib/ directory!
Thanks Josh… I guess you’re right
I fixed it.
This is extremely helpful, but I am still having issues that I am not clear how to deal with because I’m new to svn.
Say I add a new application or module with the init-* cli commands, I end up not being abcle to use svn any more (shown in log below).
Can you offer any suggestions?
dclark@soulpower2:~/htdocs/bostonready$ svn propedit svn:ignore lib/model/map/ . Set new value for property ’svn:ignore’ on ‘lib/model/map’ svn: Working copy ‘.’ locked svn: run ’svn cleanup’ to remove locks (type ’svn help cleanup’ for details) dclark@soulpower2:~/htdocs/bostonready$ svn cleanup svn: ‘apps/admin/modules/default’ is not a working copy directory dclark@soulpower2:~/htdocs/bostonready$ svn add apps/admin/modules/default/ svn: Working copy ‘apps/admin/modules’ locked svn: run ’svn cleanup’ to remove locks (type ’svn help cleanup’ for details) dclark@soulpower2:~/htdocs/bostonready$ svn up svn: Working copy ‘.’ locked svn: run ’svn cleanup’ to remove locks (type ’svn help cleanup’ for details) dclark@soulpower2:~/htdocs/bostonready$ svn help cleanup cleanup: Recursively clean up the working copy, removing locks, resuming unfinished operations, etc. usage: cleanup [PATH...]
Valid options: –diff3-cmd arg : use ARG as merge command –config-dir arg : read user configuration files from directory ARG
dclark@soulpower2:~/htdocs/bostonready$ svn cleanup . svn: ‘apps/admin/modules/default’ is not a working copy directory dclark@soulpower2:~/htdocs/bostonready$
Hi David,
Sorry Wordpress mangles up comments, so next time, if you can put your code in a <pre> block or something that might help.
Anyway, I suggest trying
svn statto see what’s going on.Chances are you’ve added stuff to your codebase but not to the repo, and it’s really just a matter of running
svn add $FILENAMEfor each new file (even those generated by your init scripts).Best
-d
You should always link to a specific revision, otherwise if you decide one day to checkout your code from a year ago, you will be checking out your old code with the newest externals plugin which may be incompatible…
Excellent post! I’ve come to the same conclusion for most of the points you make, I just forgot about the model files, so I’ll ignore those now as well.
One thing still bothers me though. How do you handle configuration, e.g. database connection? In the process of development I checkout my projects to many different servers (test server, my home dev server, production server,…) and the configuration differs for all of them. Now, I think creating a branch for each of them would be a bad idea and would imply a lot of unnecessary merging. So the best solution I can think of is to not include the config files in the repository. The problem with this is that symfony keeps it’s configuration in many different files, for example the database connection is stored in databases.yml as well as propel.ini. In addition the propel.ini file contains a lot of other configuration settings that are mostly shared across all servers, so it would be prudent to keep it in svn.
So, how do you handle configuration files when a project is run on many different servers?
Jure,
Config files can be tricky. The best solution is to create a canonical database.yml one that you use in production, but also setup to work for development (i.e. you have different databases for prod: and dev:,)
Rename this as database.yml-dist and check it in, and ignore database.yml. Then just manage them manually on all the machines. I’ve done this and it’s worked well.
The other alternative, and it’s one I use in a larger setting where we have several developers is to use symfony dimensions… but that can be a whole nother ball of wax.
Best,
-dd
Thanks for your answer, Dave. I’ve come to much the same conclusion myself. This works fine for databases.yml, because (almost) the only information stored in it is the database connection.
What about other configuration files though, that store more information, some of which is server-dependent and some is not; propel.ini for instance? This file stores the database connection and output dir, which are server-dependent, while other settings in it are not.
The same problem may arise with some user-created files like app.yml. They too may store some server-dependent information as well as server-independent one.
Of course the same technique can be applied for these as well, but then you have to remember to recreate the ignored files from *-dist ones on each server, whenever the *-dist files change (the server-independent parts).
Do you maybe have a solution for those as well?
Jure,
I usually try to keep things simple.
So with my personal projects I usually have 2 or 3 environments:
and I just use symfony’s environments to manage that. So that takes care of app.yml. I’m not super familiar with propel.ini. I don’t remember having to modify it too much.
At delicious we use dimensions, which I believe is mostly obtainable as a symfony plugin. Basically you define rules that trigger a “dimension” be it hostname, server name, something… some sort of clue. If that is triggered it will get the default .yml and other config files and anything in your triggered dimensions subdirectory.
I don’t use it much myself, so I only have a small understanding of it. But it does allow us to achieve what you seem to require.
-d
Thanks a lot for the info, Dave. I will certainly look into this “dimensions” plugin you mentioned. It sounds like just the thing I’m looking for.
Best regards, Jure
Linking the symfony library with svn:externals is a nice alternative and i was very surprised to hear that at sensio labs they are doing it the same way, since in the symfony documentation this way is not even mentioned.
But how do you people manage the project initialisation?
Do you call the cli command ’symfony init-project’ after the symfony library was embedded via svn:externals or do you start every time with a prepared symfony directory structure (apps, lib, config etc.)?
Hi John, I usually do the redundant task of having symfony installed via PEAR in advance and using the PEAR symfony command to do all the initialization.
Any update for symfony 1.1?