[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: Mike van Hoof <m.vhoof_at_scheepens.nl>
Date: Fri, 27 Jun 2008 13:08:40 +0200

Hey Everyone,
 
Thanks for the advice!
 
Had a discussion with my fellow developpers and the way Bradley explaned
his new way of working is how we are going to do it. So everybody is
going to get his own webserver in his local computer.
When somebody commits his changes a hook script is going to export a
version from the repository to the "beta" server.
 
Again thanks, and if i run into trouble i'll let you know. Also i'll
write a workflow document and post it sothat others can use it too!
 

Met vriendelijke groet,

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 <blocked::mailto:m.vhoof_at_scheepens.nl>
internet > www.scheepens.nl <blocked::http://www.scheepens.nl/>

> Opvallend veelzijdig

 

________________________________

Van: Bradley Holt [mailto:bradley.holt_at_foundline.com]
Verzonden: donderdag 26 juni 2008 17:52
Aan: Mike van Hoof
CC: users_at_subversion.tigris.org
Onderwerp: Re: Subversion workflow with PHP

Mike,

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 - 127.0.0.1 (loopback address so you use your
own web server)
        
* 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 server.

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
bradley.holt_at_foundline.com
Received on 2008-06-27 13:09:07 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.