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

Re: Merging / reintegration procedure

From: Rob van Oostrum <rvanoo_at_gmail.com>
Date: Tue, 22 Jun 2010 17:34:06 -0400

On Tue, Jun 22, 2010 at 3:47 PM, iguy <ira.l.greenstein_at_gmail.com> wrote:

> Rob,
> I realize that this is an old thread, but just in case you remember it...
> In your scheme, where do bug fixes found during testing take place?
> Ira


For example, take this scenario:

QA finds a bug in QA build #10, you have this chain (through the 'copied
from' paths/revisions you get with svn copy):

^/builds/qa/10 <-- tag created by CI server upon successful
build/deployment to QA
^/environments/qa_at_99 <-- tag created by the build manager to trigger the
build/deployment to QA
^/builds/dev/999 <-- tag created by CI server

So now you have a bunch of option as to where to fix the problem, based on
whatever your preference/process is, or sometimes the circumstances force
you down one path or another, and this approach gives you the tools to do so
elegantly, for example:

a) fix in trunk (where the other changes going into the build are)
b) create a branch from ^/trunk_at_12345 (to exclude anything on ^/trunk since
r12345), fix on branch. This is identical to a release branch approach. You
reuse the same branch for any subsequent fixes/changes related to getting
that build passed, without affecting the overall scope.
c) create a branch from wherever the problem was first reported, in this
example ^/builds/qa/10, so I don't have to think/trace where anything
originated. QA says "build 10 is broken", DEV says "we need a branch to fix
the thing that broke QA build 10", and I say "I'll give you a branch based
on QA build 10". This is makes it easier to automate e.g. for (web-based)
self-service. Potential downside is that you may end up having a bunch of
different branches containing partial fixes for something that took multiple
builds to finally resolve. But in a QA-driven process, sometimes having that
kind of traceability outweighs keeping related changes in one place.
Probably not something I would recommend as a matter of routine.

Hope that helps / gives you an idea

Received on 2010-06-22 23:34:46 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.