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.
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 <step...@sekka.co.uk>wrote:
> 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 & Evangelist http://www.jwage.com
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" <jonw...@gmail.com> 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 <step...@sekka.co.uk>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
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 <Ant.Cunning...@gmail.com> 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" <jonw...@gmail.com> 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 <step...@sekka.co.uk>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
> 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 <step...@sekka.co.uk> wrote:
> 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 <Ant.Cunning...@gmail.com> 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.
> > > 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 <step...@sekka.co.uk>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
I always freeze so that the libraries are WITH the project. I do this so that we don't have a scenario where the server libraries are upgraded, breaking my application. Having it frozen guarantees the code is 100% portable and can move from server to server without any knowledge of what version of symfony it requires.
- Jon
On Fri, Sep 26, 2008 at 3:22 PM, Ant Cunningham <Ant.Cunning...@gmail.com>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 <step...@sekka.co.uk> 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 <Ant.Cunning...@gmail.com> 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.
> > > > 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 < > step...@sekka.co.uk>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
-- Jonathan H. Wage Open Source Software Developer & Evangelist http://www.jwage.com
> > 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 <step...@sekka.co.uk> 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 <Ant.Cunning...@gmail.com> 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.
> > > > 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 <step...@sekka.co.uk>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
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 <Ant.Cunning...@gmail.com> 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 <step...@sekka.co.uk> 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 <Ant.Cunning...@gmail.com> 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.
> > > > 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 <step...@sekka.co.uk>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
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 :-)
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 <Ant.Cunning...@gmail.com> 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 <step...@sekka.co.uk> 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 <Ant.Cunning...@gmail.com> 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" <jonw...@gmail.com> 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 <step...@sekka.co.uk>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
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
> 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 <Ant.Cunning...@gmail.com> 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 <step...@sekka.co.uk> 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 <Ant.Cunning...@gmail.com> 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" <jonw...@gmail.com> 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
>>>>>> <step...@sekka.co.uk>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
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.
On Sat, Sep 27, 2008 at 11:01 AM, Olivier Mansour <omans...@gmail.com> 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 <Ant.Cunning...@gmail.com> 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 <step...@sekka.co.uk> 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 <Ant.Cunning...@gmail.com> 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" <jonw...@gmail.com> 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 >>>>>>> <step...@sekka.co.uk>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
I spent hours playing trying to get Symfoclipse working, but the pro/
cons of having the symfony code within my project far out way an IDE
tool working, so I've ditched trying to get it to work. I've just put
a couple of batch files in the project root for clearing cache and
propel build all just as a quick shortcut, everything else I will CMD
for.
I'm still debating however on whether to freeze or svn:external. I'm
thinking I may freeze as a lot of the data within the Symfony tag
folders isn't relevant for the project folder.
Thanks again all!
On 27 Sep, 08:07, Ant Cunningham <prodigital...@vectrbas-d.com> wrote:
> 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 <Ant.Cunning...@gmail.com> 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 <step...@sekka.co.uk> 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 <Ant.Cunning...@gmail.com> 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" <jonw...@gmail.com> 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 <step...@sekka.co.uk>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
> 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 :-(
> On Sat, Sep 27, 2008 at 11:01 AM, Olivier Mansour
> <omans...@gmail.com> 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 <Ant.Cunning...@gmail.com> 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 <step...@sekka.co.uk> 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 <Ant.Cunning...@gmail.com>
>>>>>> 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" <jonw...@gmail.com> 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
>>>>>>>> <step...@sekka.co.uk>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
Recently I faced the same problem (svn:externals within another
svn:externals) with Piston.
I fact "piston convert" does not work in this case.
But "piston import" works fine and has no problem handling multi-level
externals.
So if you use svn:externals in your project, first delete the
svn:externals property, then delete the directories which were related
to this external definition.
Commit these changes to your repository.
Finally use "piston import" to recover these directories and commit
this last change.
Piston is a great help ;)
Eric
On 27 sep, 19:04, "Kiril Angov" <kupokom...@gmail.com> wrote:
> 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.
> Kiril
> On Sat, Sep 27, 2008 at 11:01 AM, Olivier Mansour <omans...@gmail.com> 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 <Ant.Cunning...@gmail.com> 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 <step...@sekka.co.uk> 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 <Ant.Cunning...@gmail.com> 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" <jonw...@gmail.com> 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
> >>>>>>> <step...@sekka.co.uk>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
For the past 11 months I have been working on a project with another developer using symfony 1.0.17. I want to start using 1.1 on a personal project, problem is my work computer is my personal computer. I have tried to follow this thread, but to be honest some of it confuses. me.
I installed 1.0.17 using pear.
I moved the pear/symfony and pear/data/symfony directories to be renamed to symfony-1.0 Then I modified /usr/bin/symfony, /usr/local/ php/bin/symfony and projecname/symfony all to point to the 2 new directories. and then renamed them to symfony 1.0 (with the exception of projectname/symfony that stayed the same). Then then added PATH=".: $PATH" so that when I am in my project it looks at the symfony executable in my project directory. I then modified my config/ config.php file to point to where it needed to point too.
I've tested it, doing a "where symfony" when in the project directory gives me the projects symfony binary as working binary am able to clear cache etc...
> For the past 11 months I have been working on a project with another > developer using symfony 1.0.17. I want to start using 1.1 on a > personal project, problem is my work computer is my personal > computer. I have tried to follow this thread, but to be honest some > of it confuses. me.
> I installed 1.0.17 using pear.
> I moved the pear/symfony and pear/data/symfony directories to be > renamed to symfony-1.0 Then I modified /usr/bin/symfony, /usr/ > local/php/bin/symfony and projecname/symfony all to point to the 2 > new directories. and then renamed them to symfony 1.0 (with the > exception of projectname/symfony that stayed the same). Then then > added PATH=".:$PATH" so that when I am in my project it looks at the > symfony executable in my project directory. I then modified my > config/config.php file to point to where it needed to point too.
> I've tested it, doing a "where symfony" when in the project > directory gives me the projects symfony binary as working binary am > able to clear cache etc...
|
