Some revisions missed/skipped during SVN merge

We have had sporadic problems with merging one branch into another that are hard to detect and hard to reproduce. Some of the revisions in a range do not get merged into the destination branch. The problem is very difficult to replicate and I'm curious if other people have the same problem, or know what kind of situations can cause this.

Background: We have two example parallel development branches. Consider "Release1" created in February, "Release2" branched from that in March. We periodically merge Release1 forward into Release2 to keep them in sync. Eventually, Release1 is fully merged into Release2. This is a fairly common branching pattern, in my experience.

--- Release1 --+----+---+---+==+=x=+==*-----+---+
                \ \ \ \
                 +--Release2 -+---+--+--*--+--+---+------

The problem: at some point, when we merge a series of revisions from Release1 into Release2, the merge skips a few of the revisions from Release1 so they do not appear in Release2. In my nifty diagram above, we do a merge at the "*" point and get the two "+" changes, but not the "x" change.

Procedure:
1. Checkout clean working copy of Release2
2. Use TortoiseSVN > Merge ... > range of revisions
3. Select "specific range" with "Show Log"
4. Pick the set of revisions since the last merge which are indicated as non-greyed out
5. If necessary, edit the range field to be full range "xxxx-yyyy" instead of "xxx, b, c, d-yyy".
6. Execute the merge into local working copy
7. Commit the merge to Release2 branch

In most situations, this succeeds. In other situations, some of the revisions in the xxx-yyy range will not be merged. The files in the missing revisions don't get the changes and the revisions are not recorded as being merged when viewing history of the newly committed Release2. Often we miss this, only to discover it later when we find missing code. With large merges, it's often difficult to determine that certain files or revisions have been missed.

Sometimes, we can detect the problem prior to commit by re-executing the merge and/or reviewing the local modifications and log. The "Show Log" will indicate that there are still available revisions to merge (i.e., not greyed out).

My team has speculated about a bug in the tool, sporadic (invisible) network failures, or human error.

1. Has anyone else experienced this behavior?
2. Can anyone suggest an alternate mechanism (command line or Tortoise) to validate that all the revisions have been pulled into the local branch?

We are running SVN Server 1.7.2 (r1207936) with Tortoise SVN client 1.8.

I realize this isn't incredibly specific, but it's been very difficult to replicate this problem in a predictable manner.

Thanks for any insight into this.

Rich

----
J. Richard Mills
DevArch Application Assembly Architect
Senior Consultant | Coveros, Inc. | rich.mills_at_coveros.com | 703-585-8961
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3115751
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].