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

Leveraging Automatic Merge Management in Our Workflow

From: Jamie Jackson <myspamb8_at_gmail.com>
Date: Tue, 30 Jun 2009 17:45:45 -0400

Hi All,

I'm hoping to get some advice with regard to strategy after our recent
upgrade from server v1.4 to 1.6.

First, let me try to explain our strategy as it existed in 1.4, and
then maybe you can help me work out how to best leverage the automatic
merge management in this, or a new, strategy

Here's what evolved for us in 1.4:

For our projects (web applications) the trunk=production.

Branched from production are environment branches (test and stage).

Also branched from production are feature branches.

When a feature is ready for integration testing, it is merged into the
"test" environment branch, and when it passes muster, it then gets
merged into stage, for UAT. If it fails UAT, we repeat those first two
steps, until it's ready for production, at which point the feature
branch is merged into trunk.

This strategy has worked well for us, but we've been anxious to start
using automatic merge management, because manual tracking of merges
(in commit comments) is error prone and tedious.

However, while I've got a pretty good idea of how to use auto-merging
to sync stale branches with the trunk, and of how to reintegrate
*feature* branches into the trunk, I don't know how/if we can leverage
merge management for the environment branches.

Here's a short scenario that captures our current process in a nutshell:

A. stageEnvBranch is created from the trunk, and serves as the stage
environment branch
B. featureBranchA is created from the trunk, and will be used to
develop a feature

1. featureBranchA => stageEnvBranch (feature deployed to staging)
2. featureBranchA => trunk (feature branch deployed to trunk)
3a. (various unrelated commits to the trunk)
3. trunk => stageEnvBranch (stage branch later synced with trunk)

Is there a way to use merge management for those merges? I'm wondering
if merges 1 and 3 are incompatible: Maybe merge 1 is a case where I
need to do manually-tracked merges? I just tried something like merge
1 today, and either there's some trick I'm missing, or it is not
kosher to use merge management with anything but
ancestors/descendants. When I tried it (with these "sibling" branches,
having a common ancestor--the trunk), I got truckloads of spurious and
confusing changes.

Please help me come up a workable solution?



To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-30 23:46:48 CEST

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