> 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 again?
> 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.)
BOb
Received on 2011-05-31 20:35:59 CEST