Solved it, moved my 2 directories so they wouldn't get trashed, then
did an upgrade, all seems happy now, we'll see how well it works.
Thanks,
James
On Oct 18, 2008, at 9:23 PM, James wrote:
> OK, I need some help in this realm as well.
>
> For the past 11 months I have been working on a pro
OK, I need some help in this realm as well.
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
Hello Kiril
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 t
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 matte
Cheers for all the help guys.
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 c
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 bo
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 Cunnin
On Sat, Sep 27, 2008 at 1:08 AM, Stephen Melrose <[EMAIL PROTECTED]> wrote:
> I'm going to go down the svn:externals route.
Just one more trick, to have the three versions of symfony and their
CLI executables available on your system (eg. on your dev machine):
$ cd /usr/share/php
$ svn co http:
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
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 p
Cheers for the help Ant and Jonathan.
I'm going to go down the svn:externals route.
Lesson learned!
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 fold
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
> 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 whe
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 k
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/symfon
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 PROTE
16 matches
Mail list logo
