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

Re: Re: Branching strategy - Feature vs Release

From: Dmitri Colebatch <dim_at_colebatch.com>
Date: 2006-11-13 21:55:11 CET

On 11/13/06, Gundersen, Richard <Richard.Gundersen@london-scottish.com>
> The idea is that you commit the merged changes once they have been
> > released. You can treat the commit as a step in the release process. If you
> > only merged & released feature X, and you committing that merge, the trunk
> > certainly does reflect production. You could do X and Y at the same time if
> > you like, with the same result. The difference is, you have a CHOICE.
> >
> Ok, I've found the thing I was missing here. You sound like you don't
actually commit until you release to production. Here's how we work:

1. cut code, committing as frequently as possible without breaking the
build, tests, or general functionality (on trunk)
2. create a tag
3. release tag to test for QA
4. if required branch off the tag to fix any bugs, retag (branch) and
re-release to test. repeat as required
5. release QA'd tag to production

You sound like you're doing:

1. cut code on branch
2. once code is complete, checkout trunk and merge branch into working
copy. deploy working copy (not yet committed) to test (???)
3. once tested (how do you handle bugs?) commit to trunk and deploy to prod

I don't like the idea of the commit being part of the release process. That
could just be me, or I could have misunderstood something. To me, I want to
_know_ that we're releasing the _exact_ same thing to prod that was released
to test. Note also that frequently different people do the test and prod
releases. We have a log of what has been released and when something needs
to be released to prod the person doing the release logs into the build box,
exports the tag, builds and deploys. Some people take this even further by
committing their build artifacts and deploying those.

Received on Mon Nov 13 21:56:07 2006

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