This is something you might already have found your own solutions for, but never the less I think it's a topic people will struggle with when first using CakePHP together with SVN to version their project. However, you should already have an alright understanding for SVN itself to follow this post. If not, checkout this free svn book for information.
Ok, back to the topic. The problem is the following: You use CakePHP (or any foreign vendor, but let's keep it simple for now) to create your project and want to regulary update your version to enjoy the benifits of the frequent changes in the SVN trunk (like bug fixes, new features, etc.).
There are basically 3 options you can accomblish this:
#1 Overwriting your Project Frequently
This method might be the first one you consider, but believe me it's the worst of all. The idea is basically to frequently either export the latest SVN HEAD version from the CakePHP repository, or to visit CakePHP.org and grab the latest nightly build. Aferwards you take the new version of /cake, /index.php, /.htaccess, /VERSION.txt and use them to overwrite them with the existing ones in your working copy. Afterwards you do a commit and voilá you just updated your CakePHP version.
- Easy to understand
- If a CakePHP update breaks the application you can easily roll back
- Manual update required
- Get's hairy when you modified CakePHP core files in your working copy or when updating /app
#2 Use svn:externals
The next idea you might try is to use the svn:externals property to directly link /cake (and eventually the other 3 files in /) to the latest SVN Version. If you use TortoiseSVN (highly recommended for Windows users) this is simply a matter of right clicking the root folder of the working copy of your application's trunks and selecting properties. Then you select the Subversion tab, choose the svn:externals from the drop down on the bottom and enter "cake https://svn.cakephp.org/repo/branches/1.2.x.x/cake" in the text field below (assuming you are using CakePHP 1.2). Make sure you have deleted /cake in your working copy, then run svn update and SVN will automatically fetch the latest SVN version of the /cake folder and put it in your working copy. Whenever you run svn update from now on, you will also get the latest changes from the trunk. I think you could also link to the 3 other files in / with this method, but I haven't tried that so far.
- Easy to setup
- CakePHP Updates flow in almost automatically
- Allows modification of CakePHP core files
- Modifications to CakePHP core files will not be versioned (and therefor not be available to other people using the same repository)
- If a CakePHP update breaks your application rolling those changes back get's a bit hairy
- /app can (should) not be updated this way
#3 Use a vendor branch
Using a vendor branch is probably the most advanced of all approaches, but also the most complicated compared to the other ones. The idea is basically to create a branch for every vendor your project depends on (in our case CakePHP) and to regulary update this branch with the latest version of the vendor library. After updating the vendor branch you simply merge the changes between the previous vendor branch update and the current one into your trunk and only those changes will be applied to your application. To understand this proccess a little better I would recommend you to read this page about vendor branches I already mentioned.
- CakePHP core files can be modifed and versioned
- If a vendor update breaks the application you can easily roll back
- You can easily recieve updates to /app
- Difficult to set up
- Manual update of the vendor branch required (but you could automate this)
There is not perfect way to handle this. When working on an application with a group of developers, using a vendor branch gives you most control about the entire proccess. Personally, when working on a project all by myself I often use method #2 since it's quite simple to setup and easy to maintain. The important thing is that you know about the existing options and their advantages / disadvantages so you can choose which one suits your project best. However, method #1 should be avoided if possible ; ).
Another hint: Right now most changes to CakePHP go into the 1.2.x branch and therefor the stuff above doesn't make a lot of sense if you are working with 1.1.x right now. Currently I'm working on the new ThinkingPHP.org and another project using the 1.2.x branch and it seems pretty stable, however it's not the officially recommended version right now, so I recommend you to only do this if you are pretty familiar with CakePHP and know what you are doing.
Oh and before I forget: You should almost never have to modify anything inside /cake. Often people who do that and post their own fixes on Trac are wrong, and their problems can be solved in /app. However, never say never, being able to modify core files is still a nice option to have, *especially* when using those technics above for including other vendors that don't write as perfect code as the CakePHP developers do ; ).
--Felix Geisendörfer aka the_undefined