I have already stated that finding the exact action (commit) that created a particular reaction (broken build) is, in general, very computationally intensive, but this is so only if we have to regenerate the state of the build without any sort of caching.
Our "jar archive" is an history of all the build-produced artifacts.
Now, I wonder, is this really what we want?
If left alone, this archive will slowly saturate all existing disk space. And pretty fast.
Do we really need to save *all* the states?
I think we just need one per project: the last successful one, tagged with the day of the checkout (or the SVN revision number, whichever you want)
Gump should remove the previous ones, save space and make things more certain.
- o -
So, assuming that gump was working like that, how would a better (but still simple) algorithm work like?
Say we have project B that depends on project A.
Both projects compiled yesterday. We have artifacts from both in the archive.
Now, B doesn't build while A builds.
Whose fault is that? There is not enough information in a single build to prove that, so we have to build again, but changing the constrains.
If A builds but B doesn't, there are two possibilies:
1) B broke itself 2) A broke B
Since we know that B-yesterda built against A-yesterday, than the result of the B-today against A-yesterday will tell us if it's 1) or 2)
Ok, with two projects is easy, what about three?
C -> B -> A
worked yesterday, but today C is broken and B and A work. Who broke the build?
First of all, is it safe to assume that since A is shielded by B and both B and A work, A has no influence on C?
If so, we just apply the same algorithm for [C -> B].
thoughts?
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
