Using Subversion with eZ Publish

How do I prevent different versions of eZ Publish cache files and log files from being stored in SVN?

Tell SVN to ignore the directories that contain the files.
You can use the "svn propset" command:

http://svnbook.red-bean.com/en/1.4/svn.ref.svn.c.propset.html

http://svnbook.red-bean.com/en/1.4/svn.advanced.props.special.ignore.html

svn propset svn:ignore "*" var/cache
svn propset svn:ignore "*" var/log

Make sure to delete all the files from the cache and log directories and make sure that the directories are no longer versioned. Do not forget to commit the change using the command "svn commit".

How can I prevent changes to the files in the kernel/ and lib/ directories?

You can either use "svn lock" or a more advanced permission system. Choose the solution that best suits your needs.

http://svnbook.red-bean.com/en/1.4/svn.ref.svn.c.lock.html

http://svnbook.red-bean.com/en/1.2/svn.serverconfig.httpd.html#svn.serverconfig.httpd.authz.perdir

Using locking is faster than using the permission system. However, the locking functionality in SVN is not as flexible as the permission system. Even though it is a littile bit more work to set up, I recommend using permissions, as that system is more powerful and flexible.

Can I use Subversion as a deployment system?

Yes!

A project can be broken down into 3 stages:

• development
• testing
• production

This means you have at least three different hosts that store eachpart of the project. The idea is to reproduce these parts in SVN branches:

myproject
   |-- branches
   |  |-- testing
   |  `-- production
   |-- tags
   `-- trunk
   `-- ezpublish-4.0.0

Development is done within the 'trunk' directory. Testing is done within the 'branches/testing' directory. Production is done within the 'branches/production' directory.

What if I have to push some new code from 'trunk' to 'testing' and from 'testing' to 'production'?

Subversion gives you a powerful tool for merging changes between branches: "svn merge" [ http://svnbook.red-bean.com/en/1.4/svn.ref.svn.c.merge.html] Let us consider a complete example:

I have developped a new piece of code located in the extension directory. Since the project is in the development phase, this piece of code is only stored in the 'trunk' directory.

Therefore I have something like this:

extension/myextension

   `-- classes

       `-- myfile.php

What if I want to add this feature to the test version of the project? My changes have to be added to the "testing" branch so that they end up on the test server. First I commit my new extension:

svn commit -m 'my log message' extension/myextension

Second I copy it from "trunk" to "branches/testing":

svn copy ezpublish-4.0.0/extension/myextension ../branches/testing/ezpublish-4.0.0/extension

Third I commit the changes to the 'branches/testing' directory:

svn commit -m 'my log message' ../branches/testing/ezpublish-4.0.0/extension/myextension

In the example above, I am in the "trunk" directory. If your directory structure is different than the one we suggested above, adapt these commands so that the paths resolve correctly.

What if I only want to copy one file (for example myfile.php)?

First I commit my changes:

svn commit -m 'my log message' extension/myextension/myfile.php

Second I merge my changes between the "trunk" directory and the "testing" branch.

svn merge -rX:HEAD /path/to/my/repository/trunk/ezpublish-4.0.0/extension/myextension/classes/myfile.php

... where X is the revision number of the source file and /path/to/my/repository is the URL of the repository http://path/to/my/repository for example.

Here is a complete example of the commands used to merge a file from 'trunk' to 'branches/testing':

cd /path/to/my/repository/trunk/ezpublish-4.0.0/  

vi extension/myextension/classes/myfile2.php

   <modifying myfile2.php>

svn commit -m 'my log message' extension/myextension/classes/myfile2.php

 (the revision number is 51)

cd /path/to/my/repository/branches/testing/ezpublish-4.0.0/extension/myextension/classes/


svn merge -r51:HEAD http://path/to/my/repository/trunk/ezpublish-4.0.0/extension/myextension/classes/myfile2.php

   U   myfile2.php

And then I commit the changes with "svn commit".

You could also use the '-c X' argument with the "svn merge" command. An example is available in the documentation:

http://svnbook.red-bean.com/en/1.4/svn.branchmerge.copychanges.html

Note that the "svn merge" command may be confusing if you are not used to it. You may find this explanation useful:

http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.advancedsyntax.

I have now ported my changes from the development branch to the testing branch. I can use the same technique to port my changes from testing to production by using the "testing" branch as the source and the "production" branch as the destination.

Be careful when merging. If you forget files it can take a long time to track down the problem. Also note that merging an entire directory from one branch to another can take some time.

Subversion's tag system could also be used in this scenario. (It is described here: http://svnbook.red-bean.com/en/1.4/svn.branchmerge.tags.html.) It is a matter of your own preference. For myself, I like the idea of branching and keeping things clean and separate.

How can I use Subversion and SQL?

Using SVN to version SQL Schema is a great idea. Subversion handles SQL files the same as
any other text-based file.

You can also use SVN to store definitions that cannot be exported from the eZ Publish Administration Interface. This makes sense, for example, for the permission system. If you want to export the entire permission system from one environment to another, you can create a SQL export of the "ezrole" and "ezpolicy_xx" tables and import it in another environment.

However, do not expect SVN to be able to store SQL dumps from a production environnment. Subversion is not a SQL backup tool. If you are looking for this use a replication system.