[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion workflow with PHP

From: Bradley Holt <bradley.holt_at_foundline.com>
Date: Thu, 26 Jun 2008 11:52:25 -0400


We're currently using Subversion for PHP projects and plan on setting up a
similar process. First, let me explain our current process, then I'll
explain the better process I'm planning on implementing. We currently have
"beta" and "www" versions of each site. As work is done in the trunk, a user
will upload files to beta through FTP (everyone has their own working copy
from which they FTP their files). Sure, you can overwrite someone else's
work and mess stuff up on beta but there are few things that mitigate this.
The first rule is you should commit something before (or very shortly after)
uploading it to beta. The second rule is you should run updates often to
make sure you've got the latest code from everyone else. The third rule is,
if you upload something and didn't commit it, don't complain when someone
else overwrites your work! Files are rolled out from an svn export to www to
make sure www is always consistent. This isn't a great process, but it works
reasonably well as long as everyone understands and follows the rules.

Now, the better process I'm currently working on implementing: each user has
their own working copy which is tied to a local web server. This way each
user has total control over their working copy and can test their changes
(and only their changes) before committing. Also, users can have more
control over how often they choose to run an update and merge in repository
changes to their working copy. We're planning on using Apache's Dynamically
Configured Mass Virtual
Hosting<http://httpd.apache.org/docs/2.0/vhosts/mass.html>so that we
don't have to setup a new virtual host for every new website we
work on. So, we'd have the following entries in DNS (or you can just use
your hosts file for the local version below):

   - local.example.org - (loopback address so you use your own web
   - beta.example.org - <beta IP address>
   - www.example.org - <www IP address>

The next step would be for every commit to automatically get pushed out to
beta so that, at any given time, one can see exactly what the trunk looks
like. We're not sure exactly what mechanism we'll use for that yet. Taking
it a step further, you could have a "beta" equivalent for each maintenance
branch where changes to a particular branch are pushed out to a common web

Hope this helps! Let me know if you have any questions.

On Thu, Jun 26, 2008 at 5:23 AM, Mike van Hoof <m.vhoof_at_scheepens.nl> wrote:

> Hello everyone,
> We are using subversion for a while now, and it works like a charm, but I
> think our workflow is incorrect:
> - we have a svn server with svn and the repositories
> - we also have a webserver, with all our projects in the wwwroot. This
> projects are our working copies, so every developper works in the same
> working copy.
> So I think (no... i KNOW) that that is the wrong way to use subversion.
> I want every developper to have it's own workingcopy, but if they put
> everything local it means they have to have their own webserver running
> locally.
> An other option is that they copy every change they do to the webserver,
> but this slows down development.
> So now my question is: how would you approach this? Is there anyone who did
> this before and wants to share this with me?
> I did try to search for this on google, but didn't find what i was looking
> for...
> With kind regards,
> Mike van Hoof
> *Scheepens reclame adviseurs
> Post **›** *Postbus 954, 5000 AZ, Tilburg
> *Bezoek **›** *Sportweg 14, 5037 AC, Tilburg
> *Telefoon **›** *013 5950 900
> *Fax **›** *013 5950 901
> *e-mail **›** **m.vhoof_at_scheepens.nl*
> *internet **›** **www.scheepens.nl*
> *› Opvallend veelzijdig*

Bradley Holt
Received on 2008-06-26 20:16:09 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.