Fix bug in master/buildbot/db/sourcestamps.py

[delanne]

Dustin says:

<djmitche> you only get multiple changes attached to a sourcestamp if you have a long enough treeStableTimer that the schedule deals with both changes at the same time
<djmitche> asking "which changes led to this sourcestamp", translated to, say, git terms means "which commits led to this revision"
<djmitche> to which the only logical answer is "all of them"
<djmitche> what we really want is "what are the commits *between* this sourcestamp and that sourcestsamp"
<djmitche> so a sourcestamp will have a single change (the commit that generated it)
<djmitche> and we'll do some tree traversal to answer theq uesetion
<djmitche> but until that happens, it's this kind of crappy "it depends what the scheduler sees" answer :(

But with the current implementation, a sourcestamp is created for each change, because "revision" (GIT SHA1 in case of the gitpoller) is used to calculate the ss_hash.
As a consequence, buildbot creates a new sourcestamp for each new changes.

[djmitche]

This fix would only ever create one sourcestamp for each repository, branch, codebase, project, and patchid. Which means you'd always build exactly the same revision. Which is probably not what you or anyone wants!

[delanne]

<djmitche> ah, yes, this was partway along to the new way
<djmitche> your fix just means that there will only be one sourcestamp per branch
<djmitche> which isn't really what you want :)
<djmitche> I assume what you want is a proper blamelist?
* bb-github (~bb-github@192.30.252.33) has joined #buildbot
<bb-github> [buildbot] djmitche comment on issue #1289: This fix would only ever create one sourcestamp for each repository, branch, codebase, project, and patchid.  Which means you'd always build exactly the same revision.  Which is probably not what you or anyone wants! http://git.io/vpwXXA
* bb-github (~bb-github@192.30.252.33) has left #buildbot
<delanne> djmitche, so  PR1289 must update sourcestamps.revision in order to checkout the correct revision 
<delanne> eg the revision of the "latest" change
<delanne> right ?
<djmitche> 'update'?
<djmitche> sourcestamps don't change after they're created
<djmitche> and you'd still only have one sourcestamp
<djmitche> so all your builds would say "I built r1234" even if they atually built r1200
<delanne> I don't understand. how a sourcestamp can contain several changes in this case ?
<djmitche> it can't
<djmitche> a sourcestamp specifies a particular version of the source
<djmitche> like a tree object in git
<djmitche> it doesn't contain *any* changes
<delanne> so, currently we have no way to know which changes are included in a build ?
<djmitche> there's a change that *created* a sourcestamp
<djmitche> similar to a commit object in git
<delanne> and you said that multiple changes are attached to a sourcestamp if you have a long enough treeStableTimer ...
<djmitche> I was wrong - I forgot this was changed in nine
<djmitche> so "what changes are included in a build" is actually a function of *two* builds -- this one and the previous
<djmitche> think of "what changes are included in a build" as "git log"
<djmitche> if you just give it one revision, it gives you all changes from the first commit to that one
<djmitche> to get a limited set of commits, you need to give it two revisions
<djmitche> what's missing right now in Buildbot is a 'parent' pointer for changes
<djmitche> with that in place, the MailNotifier, etc. could calculate the equivalent of 'git log last_build..this_build'
<delanne> ok. makes sense.
 Jc2k jemand_pribyl` jklontz jochen__ jollyroger JStoker jwdevel 
<delanne> thanks djmitche 
<djmitche> it sucks that it's in an in-between state
``