Re: Leveraging Automatic Merge Management in Our Workflow

Merge tracking basically works by putting paths and revisions in
svn:mergeinfo properties. Study those very carefully.

Advice from my projects CM rules:

  The workflow is as above, but instead of reintegrate-delete, we will
  perform a record-only merge of the reintegration changeset to the
  persistent branch. Read and thoroughly understand all of
    http://blogs.open.collab.net/svn/2008/07/subversion-merg.html
  and
    http://www.collab.net/community/subversion/articles/merge-info.html
  Only the very few who really understand the previous sentence should
  do reintegrations of persistent branches. Currently A, B and
  C are the only people deemed to understand this.

Merge will record path/revision from things with or without common
ancestry, but files with common ancestry is the normal case.

Merging feature to test and then test to staging should work; when the
revisions are copied from featureA to test they will be recorded in
test, and then the merge from test to staging should copy that mergeinfo
so staging has recorded that featureA revs are there.

I see two problems with your approach:

  You should be repeatedly merging trunk into your feature branches so
  that merge issues are resolved then rather than at
  attempted-integration time. In my view, that's implicit in calling
  something a feature branch, but it doesn't sound like you mean that.
  This concept is core to svn's "--reintegrate" merge, and I think for
  feature branches you definitely want to be using that on merging back
  to trunk.

  Your test branch is going to have stuff for lots of features on it.
  When you bring it back to trunk, that's a reintegrate merge, and I
  don't see how you avoid bringing changesets from other features that
  aren't ready. And if you don't bring those, then I don't see how what
  you tested validates that what you are about to merge to trunk is
  right.

I would suggest that you have feature branches, and then when the
feature is done, declare the branch to be in staging, and then in test,
and then do a reintegrate merge back to trunk and delete the feature
branch.

If you want to do things in groups, you can have a big feature branch
for the group, and do sub-feature branches off that and reintegrate the
sub-feature branches to the main feature branch, and then test all at
once.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2367017

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].