subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob Archer <>
Subject RE: Using tags to manage releases?
Date Tue, 31 May 2011 18:35:21 GMT
> 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.

This seems strange to me. If you have a release 15 how can you then release to that version

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

What I think you might want to consider is rather that your developer "tagging" the commit
in the log message and automating moving it to your branch he should commit to trunk then
merge that committed revision to your release/15 branch.

Even more simple, if someone is working on release/15 why wouldn't they be committing changes
directly to that branch? This seems like the more common use cases.

Have you read the svn community guide on how they work there branching and release management?
 (though looks like there are some broken links there since http://subversion/docs/community-guide/releasing.html
isn't working.)

View raw message