I would go with #2.
Logically, if developer-B is done with a feature/function/bug-fix, the
branch should be frozen and merged to trunk. Then that branch can be
retired and new work should be done in a new branch. Continuing to work
in the same branch seems like a shortcut that buys you little and
creates this problem.
Your disadvantages listed for #2 are small. 2a is no big deal. And you
should re-initialize the merge tracking db for each branch anyway
(according to the doc), so 2b is non-existent.
JLM
> -----Original Message-----
> From: Reid Priedhorsky [mailto:reid@umn.edu]
> Sent: Wednesday, October 03, 2007 8:28 PM
> To: users@subversion.tigris.org
> Subject: merging best practices question
>
> Hi folks,
>
> I'm wondering the best practices in the following merge scenario. We
> are
> using the svnmerge.py script for merge tracking.
>
> Our arrangement is as follows:
>
> 1. We have two branches, trunk and branch.
> 2. The lead developer works on trunk and periodically merges from
> branch. He reviews the merged code and almost always makes changes
> before committing.
> 3. branch is "owned" by Developer B. He periodically merges from the
> trunk.
> a. Usually, the desired result after such a merge is that trunk
and
> branch are identical.
> b. Rarely, B merges only a few cherry-picked changes.
>
> The problem we are running into is that because the lead developer
> usually modifies merged code before committing it to the trunk,
> operation 3a results in a lot of conflicts, and sometimes conflicts on
> top of conflicts.
>
> I am seeking advice on how to make 3a go more smoothly. Some options
> we've come up with:
>
> 1. Write a script to wander through the WD and resolve all the
> conflicts
> in favor of the trunk version.
> Disadvantage:
> a. must figure out the logic and write a script.
>
> 2. svn rm /branches/branch
> svn cp /trunk /branches/branch
> Disadvantages:
> a. two commits when one would do
> b. copies merge tracking info to branch, where it's bogus.
> c. not sure it won't cause weirdness in branch WD
>
> Other ideas? Comments? Any other advice?
>
> Many thanks,
>
> Reid
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Oct 4 14:38:14 2007