Chris Wein <cwein@mobilygen.com> writes:
> I have a problem maintaining long-lived feature branches. The working
> model I would like is to branch at a specific revision and then
> periodically merge in new changes on the trunk into my feature branch as
> the trunk continues to move forward. After several of these merges, the
> feature is done and I would like to merge/commit the new feature back to
> the trunk. The problem I am seeing is that any conflicts that were
> resolved going from the trunk to the branch reappear as conflicts going
> back to the trunk. Now, I am sure that the to-be-scheduled (when is
> that btw? svn 2.0?) maintain merge history feature will resolve this but
> in the meantime, what can I do to eliminate these conflicts? I am not
> sure how do this, even by remembering the revision ranges I merged from
> the trunk. :-(
>
> Any ideas?
Well, you can minimize the problem by making sure that you separate
new-feature-work commits from trunk-change-porting commits to the
branch. Then when you merge back to trunk later, just merge the
revisions that involved new feature work -- don't include any of the
revisions that were only about taking changes from trunk.
In other words, to merge the feature from branch to trunk, only merge
the changes that were actually part of implementing the feature.
Don't merge changes that were about keeping the branch up-to-date with
respect to the trunk.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jul 16 21:41:22 2004