Hey In addition to your discussion I can add this note.
In a prod env, if you want to freeze your symfony version in a certain revision and keep doing svn up on your project root, you can use piston : http://piston.rubyforge.org/details.html bye Olivier Le 27 sept. 08 à 09:07, Ant Cunningham a écrit : > > Don't use Symfoclipse :-) > > Seriously, its a lot easier t manage if you just make your own > external > tool definition. I have mine set up to point to ${project_loc}/symfony > (ie. ./symfony) taking one argument - ${string_prompt} > > I just hit my hot key and type out my command in the dialog, and hit > enter. No right clicking on a certain directory or remembering which > directory serves as the context for which task... And one less plugin > which, on my dinosaur of a G4, is a good thing :-) > > I do like its YAML editor though... > > Stephen Melrose wrote: >> One more associated question. >> >> I use Eclipse, PDT and Symfoclipse to develop with Symfony. >> >> Now that I have Symfony 1.1.2 as an svn:external in /lib/vendor/ >> symfony/ and altered my ProjectConfig file to point to it, the >> Symfoclipse commands have stopped working for that project. >> >> If I make a new project in the same workspace, the commands run fine, >> only the project with the svn:external. >> >> Some playing around with the PHP in ProjectConfig led me find that >> symfoclipse functionality stops working whenever the >> sfCoreAutoload.class.php is included. >> >> Any ideas? >> >> On 26 Sep, 21:22, Ant Cunningham <[EMAIL PROTECTED]> wrote: >>>> Just to clarify, did you say you place it within /lib/vendor/ >>>> symfony/? >>>> Should it not be outside the actual symfony project folder? e.g. >>> Well i suppose that depends on how you work. We work from the >>> assumption that every project uses a different version (thought >>> thats >>> rarely the case). And when we deploy its typically to a server where >>> there is only that particular project running so we keep >>> everything in >>> the project itself. That way we dont have to bother with using >>> freeze, >>> or installing via pear on the server. We just change the necessary >>> settings (databases, propel, etc..), make a tag in svn and >>> project:deploy then build and load the data on the server. >>> >>>> Jonathan, one last question. You said I should do the external >>>> route >>>> or freeze the application. I was under the impression that you >>>> should >>>> only freeze for deployment. Is this not the case? >>> You can freeze for whatever purpose you like... Freeze basically >>> moves >>> all the necessary libs inside the project structure (similar to the >>> external method i just described). >>> >>> On Sep 26, 3:48 pm, Stephen Melrose <[EMAIL PROTECTED]> wrote: >>> >>>> Thanks for the comments. >>>> I did some playing since I posted my message and I discovered >>>> exactly >>>> what you describe. After the initial init-project, all I need to >>>> do is >>>> to set the relevant paths within the config and the symfony file in >>>> the route becomes the point of access for commands. I did not know >>>> this! I thought the command line always went to the symfony >>>> version it >>>> was setup for, but I looked at the .bat file and saw what it >>>> actually >>>> does. >>>> So projects will become a hell of a lot easier as I can just have >>>> the >>>> tag release as an external as you said. >>>> Just to clarify, did you say you place it within /lib/vendor/ >>>> symfony/? >>>> Should it not be outside the actual symfony project folder? e.g. >>>> <project> >>>> - symfonyapp >>>> - symfony1.1.2 >>>> Jonathan, one last question. You said I should do the external >>>> route >>>> or freeze the application. I was under the impression that you >>>> should >>>> only freeze for deployment. Is this not the case? >>>> Thank you both! >>>> On 26 Sep, 20:34, Ant Cunningham <[EMAIL PROTECTED]> wrote: >>>>> We use an external from lib/vendor/symfony => [release tag]. and >>>>> then >>>>> just use ./symfony to call tasks from the project directory. As >>>>> far as >>>>> keeping a copy on the system we do as John i suggesting. Our PEAR >>>>> installs are for the current release, and then we have $PEAR/ >>>>> symfony-1.0.17, $PEAR/symfony-1.2, etc.. with symlinks from $PEAR/ >>>>> symfony-1.0.17 => /usr/bin/symfony10 and so forth. Although >>>>> except for >>>>> generating the initial project, the pear installations rarely >>>>> see any >>>>> use. >>>>> On Sep 26, 2:10 pm, "Jonathan Wage" <[EMAIL PROTECTED]> wrote: >>>>>> I would keep your system up-to-date with the latest version via >>>>>> PEAR and >>>>>> then each individual symfony project should have the symfony >>>>>> libraries used >>>>>> to build the project frozen with the svn repository or included >>>>>> via >>>>>> externals. >>>>>> - Jon >>>>>> On Fri, Sep 26, 2008 at 10:43 AM, Stephen Melrose >>>>>> <[EMAIL PROTECTED]>wrote: >>>>>>> Hi there, >>>>>>> We're just coming to the end of a project here at work that we >>>>>>> built >>>>>>> using Symfony 1.0.17. >>>>>>> In the not too distant future, we will be starting our next >>>>>>> project >>>>>>> that we will be building in Symfony 1.1 (or 1.2 if it is out >>>>>>> by then). >>>>>>> However, we will also need to maintain the first project in >>>>>>> 1.0.17 for >>>>>>> the forseeable future. >>>>>>> My question is, what is the best way to have multiple versions >>>>>>> of >>>>>>> Symfony installed on one computer and develop with them, >>>>>>> hopefully at >>>>>>> the same time? >>>>>>> I have done some playing this week and I believe I achived >>>>>>> this, by I >>>>>>> want to check if what I am doing is the best method. >>>>>>> I have a folder called "Stock Code" and within it I have 2 >>>>>>> Symfony >>>>>>> folders which are check outs from the SVN. One is version >>>>>>> 1.0.17 and >>>>>>> the other is 1.1.2. I have not used PEAR. >>>>>>> If I want to develop in either version, I set my Symfony path in >>>>>>> environment variables in my system to the folder of the >>>>>>> version I am >>>>>>> working in. >>>>>>> Is this the right approach? >>>>>>> Thanks. >>>>>> -- >>>>>> Jonathan H. Wage >>>>>> Open Source Software Developer & Evangelisthttp://www.jwage.com >>> > > > -- > Ant Cunningham > Graphic Designer | Web Developer > Vector Based Design > > > -- Olivier Mansour [EMAIL PROTECTED] http://www.glagla.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" 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/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
