continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: In distributed build, how does Continuum decide whether there have been scm changes?
Date Tue, 27 Jan 2009 00:46:59 GMT

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  

- Brett

> Thanks
> --
> Marica

Brett Porter

View raw message