interaction of merge-tracking merges and cherrypicking

One of my teammates ran into a problem that I think I understand, but
I'm not really sure.

We have "feature branches", and normally we handle those by doing 'svn
merge trunkurl' to the feature branch, which merges all unmerged trunk
changesets. Then, at some point we do a reintegrate merge of the
feature branch to the trunk, followed by either deletion of the branch
or a record-only merge to the branch of the reintegration changeset.
This is all standard practice and works well (although a bit tricky).

We also have "stable branches", where we don't do automatic merges in
either direction, but do cherrypick changesets in both directions.

We have a third kind of branch, which is a cross between the two, which
is a 'semi-stable feature branch'. When we do a release (or a demo), we
want to isolate the release from changes on the trunk, and not have to
freeze the trunk. So we create a branch for the release, and call it a
feature branch. The workflow is roughly:

  We cherrypick some changesets from trunk to branch, when the release
  team decides they want the change.

  Some work is done on the release branch. Of those changesets, some
  are needed right away on the trunk, so they are cherrypicked from
  branch to trunk.

  When the release is done, we tag it.

  We do a forward merge (of all unmerged changesets) of the trunk to the
  release branch, just as if it were a regular development feature
  branch.

  We reintegrate the feature branch to trunk and delete.

The point is to get all the changes that went into the release back on
trunk; essentially a release branch is a feature branch with delayed
merging from trunk.

Recently, during the post-release forward merge to a release branch of
all unmerged changesets, we got unexplained conflicts. I think the
problem is that the changsets that are the cherrypicking of
branch->trunk should not be merged to the branch, much as the
reintegration changesets should not be merged. So, I think
cherrypicking to trunk from branch (at least for stable branches) needs
to have a record-only reverse merge of the cherrypick-effecting
changeset. Perhaps cherrypicking in general should do this.

Does this make sense to anyone else?

Is there any hope of having subversion automatically notice these
changesets, and figure out from mergeinfo that they shouldn't be merged?
That seems like too much to be done safely, so I'm thinking that it
should be integrated into the cherrypicking operation.

    Greg

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

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