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...
Office of Alan Harold, Auditor
Stark County Ohio
110 Central Plaza S
Canton, OH 44702
***Please note: My email address has changed to
>>> <richard.a.mills_at_accenturefederal.com> 05/12/15 9:33 AM >>>
> In most situations, this succeeds. In other situations, *some
> 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.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2015-05-12 16:49:14 CEST