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

Using tags to manage releases?

From: Charlie Davis <fishgills_at_fishgills.net>
Date: Tue, 31 May 2011 10:59:35 -0700

Hey everyone,
So here's what I'm trying to do and I'm wondering if I'm approaching
this all wrong.

First off, we are using Subversion for web site assets.

Since its a website, its a very "organic" property. The method of
developing towards an end goal and then releasing that, doesn't really
work for us. Meaning, everyone working in Trunk, getting Trunk to a
state we are happy, then tagging Trunk to a new branch and using that
branch for release.

What I'm doing is creating a post-commit script that, based upon flags
in the commit message, does different actions.

The idea being that someone could do say...

svn commit -m "New awesome function. REL:15" scripts/support.js

My little python script grabs the commit message, parses it out, and
the idea is that Using the REL: "tag", it does:

svn copy URL:/path/to/repo/trunk/scripts/support.js
URL:/path/to/repo/releases/15/scripts/support.js

This way we deploy individual files to our QA, stage and production
environments. Our QA department could just keep their testing copy at
the /releases/15 branch, our testing environment/production could be
different releases and our developers can continue ahead working on
different areas of the site (Maybe developer A will need 2 months to
do something, Developer B will take three days, etc...).

Remember, we don't want to do big deploys of trunk as a whole, we want
to be able to deploy parts of the site at a time.

The problem I've come across is that SVN COPY doesn't work if the file
exists... so... I made my script do a SVN delete, then a SVN COPY, and
this creates a commit... and we get an infinite loop.

Is there a better way to do this? I feel like I'm missing something.

-Charlie
Received on 2011-05-31 20:00:27 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.