On 26/01/2009, at 5:43 AM, Marica Tan wrote:
So here's my problem. As you can see from the scenario above, when
it tried
to build from agent 2 at 2:00, it checked out the project at r101
with no
scm changes.
How can it get the changes from r100 to r101? This also happens at
3:00. It
only gets the scm changes from r101 to r102. It can only have the scm
changes from r100 to r102 if it build on agent 1 again just like at
3:30
(merging of scm results will happen).
Do you know how to solve this? Any suggestions?
One of the reasons I initially thought it'd be good to attach the
agent to use to a build definition was that it meant that it wouldn't
matter - the checkout on the agent could be used to determine (because
we actually want to separate the update checks per build definition).
Here's also a solution on what Wendy wants: (though i'm not that
familiar
with version controls, just know how to use one, so I don't know if
this
will work)
1.) agent updates checkout
2.) return result with revision number?
3.) master checks if up to date and perform other checks to determine
whether agent should build the project or not. scm result may need an
additional field like "Revision Number"
4.) master then decides whether to let the agent build or not based
on #3
Is it possible to get the revision number when we do an update in
continuum?
Yep, but something to bear in mind is that not all systems support an
atomic revision number (eg, CVS). Perhaps the date could be used in
its stead here - as long as it's used consistently (with no gaps in
time) it should be fine (though date is bad to use in subversion,
since it doesn't always work).
I was actually thinking we should create a separate record from the
checkout about what the last build was anyway (as this would support
the multiple build definitions as well). This might be a good
opportunity.
- Brett
Thanks
--
Marica
--
Brett Porter
[email protected]
http://blogs.exist.com/bporter/
