Symfony Per Developer Configuration under Version Control

Are you a Symfony developer who work with several other developers, and you share your progress with them using a Version Control System (VCS)? Subversion, GIT, Mercurial, you name it. In a team based development environment, it's not uncommon that each of the developer needs to have some sort of personalized configurations. For example, in ProjectConfiguration.class.php, where you define your Symfony library include path: require_once '/home/user/projects/lib/symfony-1.4.8/lib/autoload/sfCoreAutoload.class.php';. In the single developer scheme, this works perfectly fine. However, in team development scheme under version control, this fails. That's because if you commit this file into VCS, it will alter the include path of the rest of the team.

Obvious solution are:

1) Force every person in the team to use the same include path.
2) Exclude this file from committing into VCS.

Solution (1) will probably generate a lot of rants from your teammates. What if you are using Linux and your teammate is on Windows?

Solution (2) will work, but how do you keep the changes synchronized among your teammates? You might say I don't change this file much anyway, but you do change it right? In a large project, I've change this file MANY times during the lifetime of the project. It's really annoying if I have to inform my team every time I make change to this file. This one file mentioned here is just an example, there are some other files need to be personalized too, for instance, app.yml, database.yml.

The Solution

So I propose a third solution here. Not a perfect one, but it's good enough. Here's how:
  1. Create an empty PHP file under PROJECT_ROOT/config/personalizedConfig.php. You can name this file whatever you want, I named it personalizedConfig.php. Remember to EXCLUDE this file from committing into version control system.
  2. Move the line that includes the Symfony library from PROJECT_ROOT/config/ProjectConfiguration.class.php to this file.
  3. Put the settings you want to personalized here. I created a helper class to store and retrieve setting.
  4. Include the file you've just created to ProjectConfiguration.class.php.

Now you and your teammates are free to put the Symfony library to the desired location.

Another beauty of this is that you can avoid committing sensitive information into the version control system. For example, in your database.yml, you defined production environment database information. In this case you certainly don't want it to be committed into the version control system. Symfony's yml configuration file is so well designed that you can place PHP code directly into it.

You can do likewise to app.yml. As always, you are welcome to provide your feedback below.

2 Comments Symfony Per Developer Configuration under Version Control

  1. Daniel Richter

    The recommended way is to actually store the symfony package with the project, in /lib/vendor/symfony. That way you can reference its location relatively via dirname(__FILE__)."../lib..etc" and you don't need to change the project configuration file between developers. You're also assured to all work with the same version of symfony that way.

    The only file that usually differs is the databases.yml file, which should be excluded from svn anyways for security reasons, and instead you just include a databases.yml.dist file that doesn't contain the credentials, and each developer copies and customizes that.

  2. Cuong

    - Interesting suggestion. I have multiple Symfony projects on my development machine, it's easier to manage by keeping just one copy of the library. Your suggestion is a viable one too, if one doesn't mind to have multiple copies of the library.

    - Besides databases.yml, app.yml fits in this category too. For example, when defining the website URL. Even factories.yml can be fit into this category. For example, when setting up "single_address" delivery strategy, this method will allow developers to set their preferred email address under the same environment. So instead of exclude these files from SVN, by using this method, you can commit them and yet allow other developers to change the setting to values their preferred.

Comments are closed.