Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <55E0B068.5030608@egosoft.com>
References: <55E0B068.5030608@egosoft.com>
From: Julian Foad <julianfoad@btopenworld.com>
Date: Tue, 1 Sep 2015 16:14:13 +0100
Message-ID: 
 <CAEcU=1YJUgWmyUgfHV-ahdk6F2Su_aXBaNQYsNBNEn0MVSaRgg@mail.gmail.com>
Subject: Re: E195016 on trying a normal merge / is_reintegrate_like determined
 correctly?
To: Stefan Hett <stefan@egosoft.com>
Cc: "dev@subversion.apache.org" <dev@subversion.apache.org>
Content-Type: text/plain; charset=UTF-8

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.