Hi cleve, I also use SVN to deploy my project's (ähm currently only one :-)) I use "svn propedit svn:ignore" to ignore that files on commit and commit that files as ".dist" as example: "database.yml.dist"
I use a self made script on my clients servers to update theier repos. set the permissions and run if found a updater scripts for that revision. For me that works perfect currently ( one Projekt, 2 BIG clients ). Hope i could help, Rene Jochum P.s.: I keep symfony in the sandbox way (%SF_ROOT_DIR%/lib/vendor/symfony/) as svn:external with a fixed revision cleve schrieb: > We're still using the symfony project sync, but an svn solution does > sound interesting. Few thoughts though... > > When you do an svn checkuot to the production server how do you leave > out the files you don't want like databases.yml etc > > Also what are advantages of using a checkout rather than export? > > Also do you tag every deployment in SVN then checkout from there or > just CO from the trunk and note the revision number - I could imagine > copying the whole project to a tag every time could be a bit over the > top when you're deploying daily. > > > John > > On Jul 9, 11:10 am, Gareth McCumskey <gmccums...@gmail.com> wrote: >> Well we are currently in Beta of a symfony development app and we originally >> used the symfony deploy command as it seemed (at the time) the easiest to >> use and allowed us to control when we update but it suffered from a few >> drawbacks where we had to push our local copies to the remote server and we >> could then be right in the middle of a fix for something else and hence have >> "broken" features. >> >> We switched to doing an SVN checkout. THis allowed us to control exactly >> what revision of our application was posted onto the Beta testing server >> (which some select clients have access to) and the Beta testers could also >> exactly define then which revision they were testing on making diagnosing >> bugs easier. >> >> Not to mention that ssh'ing onto the Beta test server and doing an svn up >> command was a lot easier than trying to rely on an rsync deploy... at least >> for us. >> >> In addition, we keep a frozen copy of the project in SVN. This means, >> obviously, we keep the application out of the web root directory and rather >> use Apache VirtualHost support to point to our symfony web/ directory. This >> means that we also have, at our disposal, the symfony command line tool on >> the remote box if we need it, but securely kept away from end users. >> >> On Thu, Jul 9, 2009 at 11:53 AM, Bernhard Schussek >> <bschus...@gmail.com>wrote: >> >> >> >> >> >>> Hi, >>> After an interesting discussion with Jon and Russ >>> (http://trac.symfony-project.org/ticket/6708) I would like to open a >>> follow-up thread. >>> What are your strategies for initial application deployment and for >>> delivering updates? Do you do a SVN checkout on the server or use the >>> project:deploy task? If you are using Doctrine, do you always write >>> migrations manually when making changes to the schema? What are the >>> reasons why you chose your deployment strategy? >>> I'm hoping for interesting reads :-) >>> Bernhard >> -- >> Gareth McCumskeyhttp://garethmccumskey.blogspot.com >> twitter: @garethmcc > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
