RE: Some revisions missed/skipped during SVN merge

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
>>> <richard.a.mills_at_accenturefederal.com<mailto:richard.a.mills_at_accenturefederal.com>> 05/12/15 9:33 AM >>>

> 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

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

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2015-05-12 17:49:39 CEST