Some revisions missed/skipped during SVN merge

[richard...@accenturefederal.com]

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....@coveros.com | 703-585-8961

 

 

[Gavin Lambert]

On 5/05/2015 08:35, richard.a.mills quoth:
> 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.

How many revisions are committed to Release1 between merges?

By default when you open the log window it will only load the last 100 commits. If whoever is doing the merge forgets to load extra commits, they might "miss" some of the non-greyed commits that were further down.

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3116179

To unsubscribe from this discussion, e-mail: [users-un...@tortoisesvn.tigris.org].

[richard...@accenturefederal.com]

> 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.

 

How many revisions are committed to Release1 between merges?

 

By default when you open the log window it will only load the last 100 commits.  If whoever is doing the merge forgets to load extra commits, they might "miss" some of the non-greyed commits that were further down.

 

On the order of 10-20 revisions. In one case, there were approximately 10 revisions and mystically  revisions 3,6, and 7 were skipped. It’s odd, to say the least.

 

Rich

 

 

[Ryan Hathaway]

I don't remember exactly, so I may be conflating this with some other kind of issue avoidance, but I seem to recall some prior advice on this mailing list regarding always choosing the same base folder when merging back to trunk, as opposed to merging some files from the checkout root and others from a subdirectory of the root, as some kind of metadata can be missed or not properly linked when multiple locations are involved or something like that, which I think can also cause revisions to appear to be "skipped" on complex merges.

We typically don't tend to perform many branches/merges here during our normal development workflows, so hopefully someone else with more experience can provide more detailed info for you...

Thank you,

-Ryan

Ryan Hathaway

Programmer Analyst

Office of Alan Harold, Auditor

Stark County Ohio

110 Central Plaza S

Canton, OH  44702

330-451-1414

***Please note:  My email address has changed to rghat...@starkcountyohio.gov ***

>>> <richard...@accenturefederal.com> 05/12/15 9:33 AM >>>

[richard...@accenturefederal.com]

 

I don't remember exactly, so I may be conflating this with some other kind of issue avoidance, but I seem to recall some prior advice on this mailing list regarding always choosing the same base folder when merging back to trunk, as opposed to merging some files from the checkout root and others from a subdirectory of the root, as some kind of metadata can be missed or not properly linked when multiple locations are involved or something like that, which I think can also cause revisions to appear to be "skipped" on complex merges.

We typically don't tend to perform many branches/merges here during our normal development workflows, so hopefully someone else with more experience can provide more detailed info for you...

 

Thanks, Ryan.

In general, we tend to create “cascading release branches” that link from each other as opposed to being able to go all the way back to trunk. This is largely because the “current” and “next” release branches are created in parallel with each other. It also means we tend to “forward” merge changes from the “current” release1 on to the “next” release2 branch to makes sure “next” has all the latest changes. This is, technically, similar to merging “trunk” onto the “release” branch on a regular basis.

We do use the common base directory for all merges, as opposed to trying to merge only a sub-directory at a time. I agree … I would be wary of confusing the merge info metadata in situations like that.

Rich

[André Ziegler]

I've seen other merge issue. In the merge info, revisions were added (example 1000-1008) where I only selected some (example 1000-1004, 1006, 1008).

And sometimes changes from revisions are not added correctly, only partial changes are applied. This is why I now check all modified files several times ,so tat all changes are merged correctly.

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3117132

[John Ranga Dinej Fernando]

Sometimes SVN misses out some revisions in the log and this leads to missing revisions when doing specific revision merging.

Go SVN Settings->Saved Data-> "Clear" the Log messages (Show log Dialog) before merging.