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: > trunk > 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@6 "completely" merged to source because target@5 is missing. Maybe that helps to explain it. Anyway I'll look in more detail, and look at your script, later. Regards, - Julian > 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.
