Builds scheduled with unimportant changes have the last unimportant change's revision used in the sourcestamp

[catlee]

Scenario:

User Bob pushes revision A, which is determined by the scheduler to be unimportant (e.g. by adding DONTBUILD to the comments) User Charlie pushes revision B, which is important. The scheduler triggers builds at the appropriate time.

The build's sourcestamp has two changes, A and B. But the sourcestamp's revision is A (the unimportant one), however it's actually checking out B (the important one).

Expected behaviour would be to have B as the sourcestamp's revision, since it's the more recent of the two.

Easiest fix I can think of right now is to change that line in the scheduler to say all_changes = unimportant + important...or sort all_changes by change.number.

[dustin]

I could swear we dealt with this before. Perhaps that was before the schedulerdb landed. At any rate, it's clearly broken in trunk.

[Dustin J. Mitchell]

Sort changes before attaching them to a SourceStamp?

Tested manually with an AnyBranchScheduler?

Fixes #1065

Changeset: c3e9f1e772cca6be557e4e38388da92d8ada6c9c