> On Tue, May 31, 2011 at 11:35 AM, Bob Archer <Bob.Archer_at_amsi.com>
> wrote:
> >> 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
> >
> I guess the problem I'm trying to circumvent is letting developers
> just chug away on Trunk and marking files they believe ready for
> release.
I don't understand. You stated that the developer putting REL:15 in a log message was what trigged your script to copy it into the release branch. How is that any different than having the developer merge his commit into a release branch? It doesn't have to be the developer that does it... you can have some type of promotion process or something.
>
> Having say, 4 people working on Trunk (day to day changes and what
> not
> to the site), the another 4 working on separate site features (Who
> would branch out to their own branches), how can cleanly deploy a
> set
> of new files for the site while everyone is working on their own
> version of the site?
Of course, everyone should not be working on their own version... but this seems contradictory.. you don't want everyone working in trunk but you don't want them each working on their own version. How can you have it both ways?
>
> Just having /trunk and /release might be enough (not necessarily
> release 1, 2, 3, 4, 5, 6...) might work for a website. But having
> SVN
> COPY not overwrite files is hampering this idea. This way QA can
> just
> keep their testing copy up to date to the Release branch and
> developers just put a tag into a commit message saying a file
> should
> be moved to that Release branch without having to do a svn
> delete/svn
> copy or creating an entirely new branch (This is a problem if
> someone
> is just replacing a single word in a template).
But you just told me you DONT WANT the developers to decide when something gets moved to the QA release branch. Seriously Charlie you are confusing me.
Please don't top post!
BOb
Received on 2011-05-31 21:52:47 CEST