And as I always recommend at this point of the discussion: Take a look at vendor branching in SVN <http://svnbook.red-bean.com/en/1.1/ch07s05.html>. It adds a little overhead to development, but I use it for pretty much all projects that are more than a 30-minutes-hack. I highly recommend against using external links to other repositories for production apps because you never know if the next svn update is going to break you application. If it does it will be difficult to make the external link point to a specific version of the other repository, and even more difficult to find out what's going on.
With vendor branching however, you are in control what vendor code (CakePHP in our case) you want to update when. And in the processing of doing the update you can also very clearly see what has changed it the cake core using svn diff before committing the changes to the vendor branch directory. It also allows me to 'hack' the core for short-lived issues like AD7six mentioned but keep track of these changes using svn log messages so I can revert them when I find the issues to be fixed in one of the next updates. I found this to be single best way to stay on top of current development and as I said I recommend it for everybody else out there. -- Felix Geisendörfer aka the_undefined -------------------------- http://www.thinkingphp.org http://www.fg-webdesign.de AD7six wrote: > > On Feb 19, 12:23 pm, "AD7six" <[EMAIL PROTECTED]> wrote: > >> On Feb 19, 12:00 pm, "Grant Cox" <[EMAIL PROTECTED]> wrote: >> >> >> >> >>> I'm just getting to the deployment stage of our application, and have >>> realised that simply checking out our application from version control >>> on the server is pretty neat. However, the way I've got the >>> repository set up, my app does not include the Cake core (which is >>> it's own repository, as I generally use the CakePHP nightly SVN). >>> >>> Now, I've seen SVN externals, but as far as I can tell they don't >>> actually include the foreign revision inside your own repository, >>> rather just records the foreign repository url. Plus, I don't think >>> that this will store my changes to the CakePHP core in my >>> application... >>> >>> What I'm really after is a way to check out my app, the cake core >>> revision that my application was using for the checked out revision, >>> including any modifications I've made to the cake core. Is such a >>> thing possible? Can anyone recommend a better workflow than this? >>> >> Hi Grant, >> >> I have found that using /cake as an external and saving a diff of the >> cake folder (to somewhere outside of /cake) as part of the build >> process, means that you can check out a project using externals on a >> different machine, apply the diff/patch and be up to date and good to >> go. >> >> The alternative of course is to setup a vendor branch (as Felix has >> hinted in the past ) but IMO that approach is better suited to those >> not wanting to regularly/automatically update their cake version. Also >> has the disadvantage of fattening up the svn repository which may or >> may not be a problem (the regularity with which the core gets updated, >> I wouldn't want to duplicate the cake svn version info in 2 places, >> manually, all the time). >> >> HTH, >> >> AD7six >> > > PS. I forgot to point out that in most circumstances it's not > necessary (or a good idea) to edit the core at all. I have only found > it necessary to work around (short-lived) probems or to create a patch > to add to a ticket. > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
