Thanks for the query, Stefan. I ony have time for a quick look just
now; I'll take a more detailed look at this later this week. But one
thing I can say right away... (below)
Stefan Hett wrote:
> running the attached test script brings up the following error:
> "E195016: Reintegrate can only be used if revisions 2 through 8 were
> previously merged from [branchURL] to the reintegrate source, but this is
> not the case:
> Missing ranges: branches/A:2,5"
> The weird thing here (at least weird in my understanding) is that it tries
> to do a reintegration merge even though I'm trying to perform a catach-up
> merge with trunk on the branch.
> Looking at merge.c at line 12462 the following if-check determines it's a
> "reintegrate-like" merge and therefore tries to do a reintegration merge,
> instead of a "normal" merge:
> if (base_on_source->rev >= base_on_target->rev)
> base_on_source->rev = 3
> base_on_target->rev = 4
> I'm wondering whether this if-check suffices here to determine whether it is
> a reintegration merge or not, given my test-scenario which has cherry-picked
> revisions in both directions (trunk <-> branch).
> To me it looks like the check relies on cherry-picking only being performed
> in one or the other direction, because otherwise the
> "youngest-complete-synced-point" couldn't be used to determine the direction
> for reintegration merges...
By "complete synced point" I would mean a branch-revision (such as r4
on target) at which *all* changes up to this point have been merged to
the other branch. A cherry-picked revision after that (say r6 on
target was merged to source) wouldn't make target_at_6 "completely"
merged to source because target_at_5 is missing.
Maybe that helps to explain it. Anyway I'll look in more detail, and
look at your script, later.
> Or am I missing something?
> Sorry if I'm completely off here --- not too familiar with all the details
> of the automerge and it's twisiting my brain trying to follow/interpret the
> design details from code.
Received on 2015-09-01 17:14:45 CEST