Avoiding polling source control
|
View:
New views
8 Messages
—
Rating Filter:
Alert me
|
 |
Avoiding polling source control
by Paul Butcher-4
::
Rate this Message:
We've been successfully using a patched version of CC.rb 1.1.0 for a
long time. We're just in the process of migrating to 1.4.0, however. The patch we've been using modifies CC.rb so that it doesn't need to poll source control (we were getting complaints from the guys who host our Subversion server). Instead, we use a post-commit hook to notify CC.rb that the repository has changed. I submitted this patch to the old JIRA tracking system way back: http://jira.public.thoughtworks.org/browse/CCRB-140 But got no response. I notice that things are a little more active in CC.rb-land recently, however :-) Would there be any interest in getting this functionality into the latest version? If so, I'll work on getting it into a fit state to be applied to the latest source. I'm intrigued that nobody else seems having issues with polling? ------------------------------------------------ Paul Butcher CTO Texperts Mobile: +44 (0) 7740 857648 Main: +44 (0) 1223 309080 Fax: +44(0) 1223 309082 Email: paul@... MSN: paul@... AIM: paulrabutcher Skype: paulrabutcher LinkedIn: http://www.linkedin.com/in/paulbutcher ------------------------------------------------ Re5ult Limited Registered in England No 04909795 VAT registration number GB 849 201 231. Registered office 74 Eden Street Cambridge CB1 1EL This email is confidential. It may be read, copied and used only by the intended recipient. If you have received it in error, please contact us immediately. _______________________________________________ Cruisecontrolrb-developers mailing list Cruisecontrolrb-developers@... http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers |
|
|
Re: Avoiding polling source control
by Alexey Verkhovsky-2
::
Rate this Message:
On Tue, Jul 21, 2009 at 10:32 AM, Paul Butcher <paul@...> wrote: I'm intrigued that nobody else seems having issues with polling? Never been an issue for me. Why should svn log once every few seconds be an issue, unless you have tens of these things going against the same server, all at the same time? --Alex _______________________________________________ Cruisecontrolrb-developers mailing list Cruisecontrolrb-developers@... http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers |
|
|
Re: Avoiding polling source control
by Chad Woolley
::
Rate this Message:
On Tue, Jul 21, 2009 at 9:32 AM, Paul Butcher<paul@...> wrote:
> I'm intrigued that nobody else seems having issues with polling? I would want this to be optional, and not the default. The problem with not polling is that you can miss revisions and not build if your CI server (or the network) happens to be down when the commit hook happens. This is why systems that don't support polling (like Integrity) are a no-go for me. As for the load on our subversion server, we had some problems when we had dozens of CI servers hitting our SVN, but we got around that by just increasing the polling interval on all our servers. Even that was just because we had an old crappy SVN server, when we upgraded our SVN server it had no problems with the load. -- Chad _______________________________________________ Cruisecontrolrb-developers mailing list Cruisecontrolrb-developers@... http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers |
|
|
Re: Avoiding polling source control
by Paul Butcher-4
::
Rate this Message:
On 21 Jul 2009, at 17:48, Alexey Verkhovsky wrote:
> Never been an issue for me. Why should svn log once every few > seconds be an issue, unless you have tens of these things going > against the same server, all at the same time? We have 11 projects under Cruise (with another 2 or 3 on the way) each of which uses several "svn:external"s. All up, using the default polling interval, that results in quite a lot of requests. I've no idea what kind of hardware the Subversion server's running on, but we share it with a few other clients of our hosting providers and they contacted us to ask if we could reduce the load. We can, of course, increase the polling interval, but we've got quite used to the server building immediately after a checkin. It's not essential, but it is nice to minimize the interval between a "bad" checkin and finding out about it. And a post-commit hook gives us that without any downside. ------------------------------------------------ Paul Butcher CTO Texperts Mobile: +44 (0) 7740 857648 Main: +44 (0) 1223 309080 Fax: +44(0) 1223 309082 Email: paul@... MSN: paul@... AIM: paulrabutcher Skype: paulrabutcher LinkedIn: http://www.linkedin.com/in/paulbutcher ------------------------------------------------ Re5ult Limited Registered in England No 04909795 VAT registration number GB 849 201 231. Registered office 74 Eden Street Cambridge CB1 1EL This email is confidential. It may be read, copied and used only by the intended recipient. If you have received it in error, please contact us immediately. _______________________________________________ Cruisecontrolrb-developers mailing list Cruisecontrolrb-developers@... http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers |
|
|
Re: Avoiding polling source control
by Paul Butcher-4
::
Rate this Message:
On 21 Jul 2009, at 17:57, Chad Woolley wrote:
> On Tue, Jul 21, 2009 at 9:32 AM, Paul Butcher<paul@...> > wrote: >> I'm intrigued that nobody else seems having issues with polling? > > I would want this to be optional, and not the default. The problem > with not polling is that you can miss revisions and not build if your > CI server (or the network) happens to be down when the commit hook > happens. This is why systems that don't support polling (like > Integrity) are a no-go for me. Of course. We actually use a hybrid scheme with a very long polling interval (12 hours, although clearly this could be tailored to suit local conditions) which helps catch that case. ------------------------------------------------ Paul Butcher CTO Texperts Mobile: +44 (0) 7740 857648 Main: +44 (0) 1223 309080 Fax: +44(0) 1223 309082 Email: paul@... MSN: paul@... AIM: paulrabutcher Skype: paulrabutcher LinkedIn: http://www.linkedin.com/in/paulbutcher ------------------------------------------------ Re5ult Limited Registered in England No 04909795 VAT registration number GB 849 201 231. Registered office 74 Eden Street Cambridge CB1 1EL This email is confidential. It may be read, copied and used only by the intended recipient. If you have received it in error, please contact us immediately. _______________________________________________ Cruisecontrolrb-developers mailing list Cruisecontrolrb-developers@... http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers |
|
|
Re: Avoiding polling source control
by Chad Woolley
::
Rate this Message:
On Tue, Jul 21, 2009 at 1:22 PM, Paul Butcher<paul@...> wrote:
> On 21 Jul 2009, at 17:48, Alexey Verkhovsky wrote: >> >> Never been an issue for me. Why should svn log once every few seconds be >> an issue, unless you have tens of these things going against the same >> server, all at the same time? > > > We have 11 projects under Cruise (with another 2 or 3 on the way) each of > which uses several "svn:external"s. All up, using the default polling > interval, that results in quite a lot of requests. I've no idea what kind of > hardware the Subversion server's running on, but we share it with a few > other clients of our hosting providers and they contacted us to ask if we > could reduce the load. One other thing - I have noticed if you do commits ACROSS externals and a parent project, this can really kill the SVN server to resolve the log especially if it isn't beefy. It was thrashing or something, probably IO bound reading different locations in repo. To mitigate this, I got in the habit of doing separate commits for externals vs. parent project - or alternately do a dummy commit to the parent project after the externals commit, so that shows up in the cruise log instead of the big cross-repo commit. Maybe that is your current problem? _______________________________________________ Cruisecontrolrb-developers mailing list Cruisecontrolrb-developers@... http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers |
|
|
Re: Avoiding polling source control
by Paul Butcher-4
::
Rate this Message:
On 21 Jul 2009, at 21:41, Chad Woolley wrote:
> One other thing - I have noticed if you do commits ACROSS externals > and a parent project, this can really kill the SVN server to resolve > the log especially if it isn't beefy. It was thrashing or something, > probably IO bound reading different locations in repo. To mitigate > this, I got in the habit of doing separate commits for externals vs. > parent project - or alternately do a dummy commit to the parent > project after the externals commit, so that shows up in the cruise log > instead of the big cross-repo commit. Maybe that is your current > problem? I doubt it, because the issue definitely seems to be caused by CruiseControl polling (i.e. when we stop it from doing so, the server can cope just fine). But thanks for the suggestion! ------------------------------------------------ Paul Butcher CTO Texperts Mobile: +44 (0) 7740 857648 Main: +44 (0) 1223 309080 Fax: +44(0) 1223 309082 Email: paul@... MSN: paul@... AIM: paulrabutcher Skype: paulrabutcher LinkedIn: http://www.linkedin.com/in/paulbutcher ------------------------------------------------ Re5ult Limited Registered in England No 04909795 VAT registration number GB 849 201 231. Registered office 74 Eden Street Cambridge CB1 1EL This email is confidential. It may be read, copied and used only by the intended recipient. If you have received it in error, please contact us immediately. _______________________________________________ Cruisecontrolrb-developers mailing list Cruisecontrolrb-developers@... http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers |
|
|
Re: Avoiding polling source control
by Chad Woolley
::
Rate this Message:
On Wed, Jul 22, 2009 at 7:09 AM, Paul Butcher <paul@...> wrote:
I'm pretty sure polling causes log queries to be performed against the server to check for updates, so it could be part of your problem! _______________________________________________ Cruisecontrolrb-developers mailing list Cruisecontrolrb-developers@... http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers |
| Free embeddable forum powered by Nabble | Forum Help |
