On 8/25/07, Troy Curtis Jr <troycurtisjr@gmail.com> wrote:
> We have a recurring issue in our development that I was curious to see
> how other people handle it and most curious to see if the new
> merge-tracking for 1.5 will solve the issue.
>
> There are three branches:
>
> trunk --- Mainline development (duh :))
> task_branch -- temporary branch off of trunk for working a particular task
> release 1.0 branch -- Stable release branch originally off trunk (a while back)
>
> So you are working along making commits to "task_branch". Eventually
> you merge all your changes (or some subset) from the "task_branch"
> back into "trunk", complete with the svnmerge maintained property
> (svnmerge-integrated). It turns out your changes fix an issue that
> exists in the "release 1.0 branch" so you dutifully merge the changes
> from "trunk" to "release 1.0 branch". The trouble is, that revision
> on trunk contains a modification to the 'svnmerge-integrated' property
> because it was performed with svnmerge, but *this* svnmerge operation
> ALSO modified svnmerge-integrated and so it produces a conflict.
>
> It does appear to be alway safe to resolve the conflict on the second
> merge immediately as you don't really want the trunk merge-tracking
> info. However, it seems quite clunky and I know that some of the less
> sophisticated users get confused when it happens.
>
> What do other people do to address this situation? With this still be
> a problem with the new merge-tracking in 1.5?
The merge tracking feature added special code to intelligently merge
the merge tracking information, so this should not be an issue.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Aug 26 01:38:08 2007