The problem with Wendy's logic is that it works really well for SVN or
P4 with atomic commits, but not so much for CVS. On the other hand,
the build agent checking its local workspace isn't great, because
another agent may have built. An option would be to call a timestamp
as of the build scheduled time, and determine if there have been
changes between the previous build's timestamp and the current
timestamp. On most atomic commit systems this is translated
immediately into a revision number, but for something like CVS, each
client can determine whether changes occur between TimeA and TimeB.
Or maybe use revision and fall back on timestamps for non-atomic
commit systems.
A lot of what I said is stated without really solid understanding of
the continuum SCM infrastructure, so I'm not sure if the features are
there, but they should be in the underlying SCM system being used.
Christian.
On 22-Jan-09, at 21:07 , Marica Tan wrote:
On Tue, Jan 20, 2009 at 9:15 AM, Wendy Smoak <[email protected]> wrote:
I'm trying to understand how, if a project may build on any agent,
Continuum can determine whether there have been scm changes since the
last time it was built. Here's what I think should happen (scheduled
builds, assuming Always Build and Build Fresh are NOT checked):
Add project
1:00pm Build on agent 1, checkout at r500
2:00pm Build on agent 2, checkout at r500 <--- no changes, project
should not build
2:15pm developer makes scm changes
3:00pm Build on agent 2 update to r501, build because there were
changes
4:00pm Build on agent 1 update to r501 <---- no changes, project
should not build
This is possible, but IMO the master needs to keep track of the
revisions so
that when agent 1 tries to build project @ 4:00pm it will only
update the
working copy but it won't build the project.
Our initial plan is to have a dumb build agent so all it knows is
how to
build. When it's a scheduled build, it will always build regardless
if there
is or there isn't any change at all. We can add the check for
whether it
should build or not in the next pass.
But I'm not sure how Continuum makes its determination of whether
there have been changes, (even without Distributed Build.)
It first updates the working copy and then set the project's scm
result
(with scm changes). Project has a one to one relationship with
ScmResult.
Everytime you update the working copy, it merges the new scm changes
with
the old scm changes unless it says build fresh.
Currently, no scm changes is returned to the master in a distributed
build
and I'll be working on that next.
This is a bit of a pain to set up and test for, so I'm hoping someone
will reassure me that it will all work fine. :)
--
Wendy
Christian E. Gruber - President / Senior Consultant
Isráfíl Consulting Services Corporation
email: [email protected]
mobile: +1 (289) 221-9839
web: http://www.israfil.net/
"...keenness of understanding is due to keenness of vision."
