[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: 1.8.x backport conflicts bot is red

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Sat, 28 Feb 2015 21:39:39 +0000

Philip Martin wrote on Sat, Feb 28, 2015 at 13:38:12 +0000:
> Philip Martin <philip.martin_at_wandisco.com> writes:
>
> > I could change the proposal
> > but I don't know if the backport script would then interpret Daniel's
> > vote for the other revisions as approving the whole backport:

It wouldn't. The mergebot doesn't parse parenthetical comments in
votes. It merges an entry if the following criteria are met: there are
no -1 votes and the last section header seen was "Approved changes".
(In particular, the number of +1 votes doesn't matter, even if it is one
or zero.) The r1659867 group is not in the "Approved changes" section
so it won't be auto-merged.

That's documented, here:

    % cd trunk-wc
    % ./tools/dist/backport.pl --help | me
    There are two batch modes. The first mode is used by the nightly svn-role
    mergebot. [...] In this mode, the script will iterate the "Approved changes:"
    section and merge and commit each entry therein. To prevent an entry from
    being auto-merged, veto it or move it to a new section named "Approved, but
    merge manually:".

> I don't think the backport script would do that but changing the
> proposal looks like the wrong thing: the 'missing' revisions are
> proposed for merge to 1.8.x just not from trunk. I suppose we could
> change the backport script to also look for 'missing' revisions in the
> commits made to the proposed branch.

Done in r1663005. This should make the conflicts bot green at its next
hourly run, even if your patch to edit the STATUS entry is not applied.
[ Update: I see Bert has applied that patch before I got this mail sent. ]

Cheers,

Daniel

> --
> Philip
Received on 2015-02-28 22:40:09 CET

This is an archived mail posted to the Subversion Dev mailing list.