Le 27 sept. 08 à 19:04, Kiril Angov a écrit :
> Piston did not work with the Symofony repository because it does not > handle when the svn:external has an svn:external by itself. > I > submitted a bug report and the guy said he will fix it for version 2.0 > and that is not out yet. As a matter of fact it is not updated since > early 2008 so I would not bother figuring out Piston just to find the > problem I faced some months ago. thanks for the notes. I am discovering those points. Its not very comfortable if this soft seems no more maintained :-( Olivier > > > Kiril > > On Sat, Sep 27, 2008 at 11:01 AM, Olivier Mansour > <[EMAIL PROTECTED]> wrote: >> >> 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 >> >> >> >>> >> > > > -- 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 -~----------~----~----~----~------~----~------~--~---
