You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by brunoml <br...@worldonline.fr> on 2006/02/24 09:08:14 UTC
'good practices' in php programming with subversion
Hi,
I would like to know what are 'good practices' in php programming :
- working copy on programmer's computers, copy (with a batch, a macro in IDE) to
"test/debug" web server and commit
- working copy on "test/debug" web server (so, several programmers on the same
WC) and commit.
- other...
Thanks !
--
Bruno
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 'good practices' in php programming with subversion
Posted by brunoml <br...@worldonline.fr>.
On 24 Feb 2006 at 14:09, Ryan Schmidt wrote:
>
> On Feb 24, 2006, at 10:08, brunoml wrote:
>
> > I would like to know what are 'good practices' in php programming :
> >
> > - working copy on programmer's computers, copy (with a batch, a
> > macro in IDE) to
> > "test/debug" web server and commit
> > - working copy on "test/debug" web server (so, several programmers
> > on the same
> > WC) and commit.
> > - other...
>
> Please read this thread; a discussion of your question comes up in it:
>
> http://svn.haxx.se/users/archive-2006-02/0991.shtml
Thanks ! I'll read this...
--
Bruno
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 'good practices' in php programming with subversion
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Feb 24, 2006, at 10:08, brunoml wrote:
> I would like to know what are 'good practices' in php programming :
>
> - working copy on programmer's computers, copy (with a batch, a
> macro in IDE) to
> "test/debug" web server and commit
> - working copy on "test/debug" web server (so, several programmers
> on the same
> WC) and commit.
> - other...
Please read this thread; a discussion of your question comes up in it:
http://svn.haxx.se/users/archive-2006-02/0991.shtml
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 'good practices' in php programming with subversion
Posted by Darko Miletic <da...@uvcms.com>.
brunoml wrote:
>> My preference (and what we do with our Java web app):
>> Each dev has his own working copy
>> Each dev has, on his desktop, a unit testing environment
>> The central dev server is used for integration testing of all changes.
>> Code only gets to this server via svn checkout, developers cannot
>> copy files to it directly.
>
> Yes, but 'testing environment' mean apache+php on each dev desktop :-(
>
> This is what I would like to avoid... (but no better idea...)
There is no need fo that. You just need a server with remote php
debugger (Zend recommended).
What we use in company where I work is CVS server on one machine, and
all developers commit there.
On every commit CVS runs post-commit script that connects to debug
server with apache, php and zend debugger, updates cvs managed content
with cvs update and then developers can debug directly on server.
Works like a charm.
BTW developers do not need apache on their windows machines, IIS works
just the same.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: 'good practices' in php programming with subversion
Posted by Jonathan Chum <jc...@aismedia.com>.
I have a very similar setup. Since many of our projects are modular, we
commit everything into trunk and won't be trampling on each other too much.
Since many of the projects also involved designers, there's the occasional
issue where we have merge HTML docs together. This is tough because one tag
conflict can mess up an entire layout.
On the SVN FAQ, there's a code snippet that when compiled, will pushed
everything in a trunk folder into a "staging" area which is always an
up-to-date trunk version until the database schema becomes out of sync.
Otherwise, it works great for graphic designers who aren't going to be
installed XAMP locally on their machine for testing, but need a way to see
their work along side my development portion.
Installing XAMPP will not require admin rights and can be installed/removed
without any issues.
We try not to use anything "unique" in the Apache conf and all of projects
exist in the default "htdocs" folder. So there's no need to change the
Apache conf at all.
As far as the database changes are concerned, the schema is outlined with
all the developers on a project so the only changes to it will be "test"
data. The schema should not be changed too much after the initial schema
design.
The better approach would be to house the MySQL database in a development
box centralized for anyone involved in the project can connect to. Then a
script will perform an hourly hot backup just incase something were to
happen to it.
> -----Original Message-----
> From: brunoml [mailto:bruno2.boudinski@worldonline.fr]
> Sent: Friday, February 24, 2006 9:46 AM
> To: users@subversion.tigris.org
> Subject: Re: 'good practices' in php programming with subversion
>
>
>
> On 24 Feb 2006 at 8:10, Andy Levy wrote:
>
> > On 2/24/06, brunoml <br...@worldonline.fr> wrote:
> > > Hi,
> > >
> > > I would like to know what are 'good practices' in php programming :
> > >
> > > - working copy on programmer's computers, copy (with a batch, a macro
> in IDE) to
> > > "test/debug" web server and commit
> > > - working copy on "test/debug" web server (so, several programmers on
> the same
> > > WC) and commit.
> > > - other...
> >
> > If everyone works from the same working copy, then aren't you losing a
> > lot of the collaborative ability SVN gives you? Your chances of
> > trampling over each others' code go up significantly IMO. Plus you
> > all have to remember to specify --username on each commit (or
> > otherwise require a login for each update/commit), else you can't
> > reliably identify who made what changes.
> >
> > My preference (and what we do with our Java web app):
> > Each dev has his own working copy
> > Each dev has, on his desktop, a unit testing environment
> > The central dev server is used for integration testing of all changes.
> > Code only gets to this server via svn checkout, developers cannot
> > copy files to it directly.
>
> Yes, but 'testing environment' mean apache+php on each dev desktop :-(
>
> This is what I would like to avoid... (but no better idea...)
>
> Thanks
> --
> Bruno
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 'good practices' in php programming with subversion
Posted by brunoml <br...@worldonline.fr>.
On 24 Feb 2006 at 8:10, Andy Levy wrote:
> On 2/24/06, brunoml <br...@worldonline.fr> wrote:
> > Hi,
> >
> > I would like to know what are 'good practices' in php programming :
> >
> > - working copy on programmer's computers, copy (with a batch, a macro in IDE) to
> > "test/debug" web server and commit
> > - working copy on "test/debug" web server (so, several programmers on the same
> > WC) and commit.
> > - other...
>
> If everyone works from the same working copy, then aren't you losing a
> lot of the collaborative ability SVN gives you? Your chances of
> trampling over each others' code go up significantly IMO. Plus you
> all have to remember to specify --username on each commit (or
> otherwise require a login for each update/commit), else you can't
> reliably identify who made what changes.
>
> My preference (and what we do with our Java web app):
> Each dev has his own working copy
> Each dev has, on his desktop, a unit testing environment
> The central dev server is used for integration testing of all changes.
> Code only gets to this server via svn checkout, developers cannot
> copy files to it directly.
Yes, but 'testing environment' mean apache+php on each dev desktop :-(
This is what I would like to avoid... (but no better idea...)
Thanks
--
Bruno
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 'good practices' in php programming with subversion
Posted by Andy Levy <an...@gmail.com>.
On 2/24/06, brunoml <br...@worldonline.fr> wrote:
> Hi,
>
> I would like to know what are 'good practices' in php programming :
>
> - working copy on programmer's computers, copy (with a batch, a macro in IDE) to
> "test/debug" web server and commit
> - working copy on "test/debug" web server (so, several programmers on the same
> WC) and commit.
> - other...
If everyone works from the same working copy, then aren't you losing a
lot of the collaborative ability SVN gives you? Your chances of
trampling over each others' code go up significantly IMO. Plus you
all have to remember to specify --username on each commit (or
otherwise require a login for each update/commit), else you can't
reliably identify who made what changes.
My preference (and what we do with our Java web app):
Each dev has his own working copy
Each dev has, on his desktop, a unit testing environment
The central dev server is used for integration testing of all changes.
Code only gets to this server via svn checkout, developers cannot
copy files to it directly.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org