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

Re: Best practices for web developers?

From: Andy Levy <andy.levy_at_gmail.com>
Date: Tue, 12 May 2009 15:17:07 -0400

On Tue, May 12, 2009 at 15:09, pileofrogs <pileofrogs_at_gmail.com> wrote:
> Hello, I'm a network admin trying to get some web developers onto
> SVN.  They're accustomed to editing the files on the server directly
> (or nearly so).  I've tried showing them SVN and they seem perplexed.
> The work flow of checkout->change->checkin->ssh-to-server->checkout-
>>build is pretty darn unwieldy.  Is there anything approaching a 'best
> practice' for web developers using SVN?  Here's the thoughts I've had:
> 1) put a web server on the desktop - this follows the typical software
> app developers workflow where you compile and test on your local
> machine.  Still needs a way to deploy to 'test' and 'live' servers,
> but it isn't used as often so it can be a little unwieldy.

Revoke their access to the servers, so they don't have the ability to
get around the system and *have* to work this way. Only release
managers (well, except for the next segment) can deploy to the
servers. Last I knew this was MS's recommendation for how to do web
development on their platform(s) - code local, test local, then push
to an integration test server.

> 2) Use commit hooks to automatically update content on the web server
> - simpler, but allows collisions between developers trying to see
> effects of code.  Needs a way to see different branches/revisions.

Can also release broken code to your servers if developers don't test
thoroughly enough (see above) or at all. My preference is to only
deploy to the server once I know it's a good build.

> 3) Instead of commit hooks, make a web page that updates the displayed
> content.  One more step for developer and more control over branches/
> revisions displayed.  Can still have collisions on server.
> 4) Set up multiple web servers.  This avoids the collisions, but still
> requires a good way to deploy changes.

Or give each developer his own virtual site on the same server. But
this isn't too far removed from 1/2.

> 5) Keep doing it by hand.  Just grill the humans to checkout, change,
> checkin, ssh, checkout, build...

Automate what you can, and restrict access enough that you can be
reasonably assured that developers will have to work hard to cause a


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-05-12 21:17:35 CEST

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

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