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 <bruno2.boudinski@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
Received on Fri Feb 24 17:57:52 2006