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)
When we copy from the SVN or CVS areas (from server) to the Gump work area, we detect if any files have changed (server side). As such, we could store (for as long as sensible) the last N changed outputs. [We only know modules changes, so each project is marked as change when a module changes. This is bad for jakarta-commons, but tolerable elsewhere, IMHO.]
Gump should remove the previous ones, save space and make things more certain.
Yup (in general).
If so, we just apply the same algorithm for [C -> B].
Thoughts?
Why not? If (say, as now) 70+% of the Gump tree is building, it is only the 'Gump high water mark' (http://brutus.apache.org/gump/public/project_todos.html) that we need to do this for. Gump cycles on build (during successes) are almost boring; the paint has dried but we are still looking. Spending cycles on the failures (however expensive) on new members of the Gump tide line, seems very worth while to me.
I am sure there are cases (i.e. both changed) when the combinatorial won't give us an answer, but hey -- in those case (on first ever event) -- why not notify all players. Gump ought work upstream, not just downstream, IMHO.
I like this, I hope we get there soon with it. Personally, I also thing that it is time to start parsing the ant output (like Leo mentioned before) and looking for clues. We ought be able to take a compile error, detect the package, calcualte what project that is from, and target that one. I believe that is an avenue to explore soon...
regards,
Adam
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
