You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@wandisco.com> on 2015/02/28 11:54:56 UTC
1.8.x backport conflicts bot is red
The error message is:
1.8.x-r1659867 (Fix reproducable memory corruption and unneeded io
errors on editor abort): Revisions 'r1660091, r1660097' nominated but
not included in branch
I think the fix is obvious; Philip, I think you nominated those two
revisions? Do you want to update the backport branch, too?
-- Brane
Re: 1.8.x backport conflicts bot is red
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Philip Martin wrote on Sat, Feb 28, 2015 at 13:38:12 +0000:
> Philip Martin <ph...@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
Re: 1.8.x backport conflicts bot is red
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Bert Huijben wrote on Sat, Feb 28, 2015 at 21:17:16 +0100:
>
>
> > -----Original Message-----
> > From: Philip Martin [mailto:philip.martin@wandisco.com]
> > Sent: zaterdag 28 februari 2015 19:13
> > To: Bert Huijben
> > Cc: Philip Martin; Branko Čibej; Daniel Shahaf; Subversion Development
> > Subject: Re: 1.8.x backport conflicts bot is red
> >
> > Bert Huijben <be...@qqmail.nl> writes:
> >
> > > I would have expected that the backport script would *only* look at
> > > the branch, as that is what would have to be merged once accepted.
> >
> > I suppose I could do the trivial merge from trunk and generate a
> > mergeinfo change on the branch. That would probably satisfy the
> > backport script.
>
> I don't think the backport script is really that advanced.
> As far as I can tell it just tries the backport and notes problems.
>
> In this case it should have tried the reintegrate from branch.
>
If an entry mentions a branch then the 'svn merge' command run by the
nightly bot will use the branch (and ignore the revisions specified).
However, both the mergebot (nightly) and the conflicts bot (hourly) now
check that the branch contains all revisions named on the "*" line.
Makes sense?
>
> Daniel tweaked the script this week for some other merge problems (related to 1.9). Perhaps this is related.
No, it's related to r1661252 which was committed on Feb 21, not to
r1662760 which was committed yesterday.
Daniel
RE: 1.8.x backport conflicts bot is red
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Philip Martin [mailto:philip.martin@wandisco.com]
> Sent: zaterdag 28 februari 2015 19:13
> To: Bert Huijben
> Cc: Philip Martin; Branko Čibej; Daniel Shahaf; Subversion Development
> Subject: Re: 1.8.x backport conflicts bot is red
>
> Bert Huijben <be...@qqmail.nl> writes:
>
> > I would have expected that the backport script would *only* look at
> > the branch, as that is what would have to be merged once accepted.
>
> I suppose I could do the trivial merge from trunk and generate a
> mergeinfo change on the branch. That would probably satisfy the
> backport script.
I don't think the backport script is really that advanced.
As far as I can tell it just tries the backport and notes problems.
In this case it should have tried the reintegrate from branch.
Daniel tweaked the script this week for some other merge problems (related to 1.9). Perhaps this is related.
Bert
>
> --
> Philip Martin | Subversion Committer
> WANdisco // *Non-Stop Data*
Re: 1.8.x backport conflicts bot is red
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Philip Martin wrote on Sat, Feb 28, 2015 at 18:12:47 +0000:
> Bert Huijben <be...@qqmail.nl> writes:
>
> > I would have expected that the backport script would *only* look at
> > the branch, as that is what would have to be merged once accepted.
>
> I suppose I could do the trivial merge from trunk and generate a
> mergeinfo change on the branch. That would probably satisfy the
> backport script.
Why are you *guessing* how the script works? If something is not clear,
please ask, so the documentation may be improved.
The bits you speculated about are documented here (this is the old
documentation, before today's patch):
% ./tools/dist/backport.pl --help | me
Both batch modes also perform a basic sanity-check on entries that declare
backport branches (via the "Branch:" header): if a backport branch is used, but
at least one of the revisions enumerated in the entry title had not been merged
from ^/subversion/trunk to the branch root, the hourly bot will turn red and
nightly bot will skip the entry and email its admins. (The nightly bot does
not email the list on failure, since it doesn't use buildbot.)
If there are any other questions about backport.pl, how it works, etc.,
I'd be happy to answer. Fire away.
Cheers,
Daniel
Re: 1.8.x backport conflicts bot is red
Posted by Philip Martin <ph...@wandisco.com>.
Bert Huijben <be...@qqmail.nl> writes:
> I would have expected that the backport script would *only* look at
> the branch, as that is what would have to be merged once accepted.
I suppose I could do the trivial merge from trunk and generate a
mergeinfo change on the branch. That would probably satisfy the
backport script.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
RE: 1.8.x backport conflicts bot is red
Posted by Bert Huijben <be...@qqmail.nl>.
I would have expected that the backport script would *only* look at the branch, as that is what would have to be merged once accepted.
Daniel?
Bert
-----Original Message-----
From: "Philip Martin" <ph...@codematters.co.uk>
Sent: 28-2-2015 14:39
To: "Branko Čibej" <br...@wandisco.com>
Cc: "Subversion Development" <de...@subversion.apache.org>
Subject: Re: 1.8.x backport conflicts bot is red
Philip Martin <ph...@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:
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.
--
Philip
Re: 1.8.x backport conflicts bot is red
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@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:
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.
--
Philip
Re: 1.8.x backport conflicts bot is red
Posted by Philip Martin <ph...@wandisco.com>.
Branko Čibej <br...@wandisco.com> writes:
> The error message is:
>
> 1.8.x-r1659867 (Fix reproducable memory corruption and unneeded io
> errors on editor abort): Revisions 'r1660091, r1660097' nominated but
> not included in branch
>
> I think the fix is obvious; Philip, I think you nominated those two
> revisions? Do you want to update the backport branch, too?
Those two revisions were committed directly to the branch and there is
no corresponding trunk revision to merge. 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:
Index: ../src-1.8/STATUS
===================================================================
--- ../src-1.8/STATUS (revision 1662924)
+++ ../src-1.8/STATUS (working copy)
@@ -88,7 +88,7 @@
+0: danielsh (hard to review all potential causes of expanded_size==0 in
7*3*2 cases (1.1…1.8) × (file/dir/prop rep) × (plain/delta))
- * r1659867, r1659869, r1660091, r1660097
+ * r1659867, r1659869
Fix reproducable memory corruption and unneeded io errors on editor abort
Justification:
Reproducible double free(), which is undefined behaviour. Details:
@@ -103,6 +103,7 @@
Notes:
'svn import -mm | (sleep 2; cat)' followed by ^C at the right time was
the reproduction.
+ r1660091, r1660097 included on branch.
Branch:
^/subversion/branches/1.8.x-r1659867
Votes:
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*