[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: merging best practices question

From: Srilakshmanan, Lakshman <lakshman.srilakshmanan_at_police.vic.gov.au>
Date: 2007-10-04 05:02:20 CEST

Hi Reid,

The following steps should work, assuming more work has not been done on
the branch since merging to trunk. If additional work has been done then
DON'T use HEAD use the revision number on the branch associated at the
time of merge into trunk.
Perform a dry run before attempting a merge. This merge should be done
at 3a as per your example.
A) svn co branch-b
B) cd branch-b
C) svn merge http://.../branch/B@HEAD http://..../trunk@HEAD

The above merge should identify all steps required to make branch-b
mirror trunk and apply the change to WC. If no change has been done on
the branch since the merge into trunk, then you should see no conflicts.

Thanks
lakshman
-----Original Message-----
From: Reid Priedhorsky [mailto:reid@umn.edu]
Sent: Thursday, 4 October 2007 10:28 AM
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

================================================================================================
EMAIL DISCLAIMER

This email and any attachments are confidential. They may also be subject to copyright.

If you are not an intended recipient of this email please immediately contact us by replying
to this email and then delete this email.

You must not read, use, copy, retain, forward or disclose this email or any attachment.

We do not accept any liability arising from or in connection with unauthorised use or disclosure
of the information contained in this email or any attachment.

We make reasonable efforts to protect against computer viruses but we do not accept liability
for any liability, loss or damage caused by any computer virus contained in this email.
================================================================================================

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Oct 4 05:02:22 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.