[M3devel] Hudson setup and M3 repository, was: Re: VM for I386_NETBSD Hudson

[Jay K]

All the more reason to use anything besides CVS?
 
 
What about checkout vs. update?
  Is update a problem or just checkout?
  We don't do many checkouts, right?
 
 
Can/should the pollling interval be changed, like to every hour?
And can machines poll at different times, say at a minute within the hour that is a hash of their hostname?
 
 
Or more aggressive, have some machines only poll a few times a day, once or twice?
Only more mainstream machines poll more frequently?
I can always run "build now" if I'm eager for a particular build.
 
 
Repository size is a tough one.
Even if I remove files, the repository size is unchanged, right?
We have 3 copies of gcc in semi-active use right now.
 There are others in the repository.
But gcc-apple really isn't active -- it is for ARM_DARWIN.
Can the Hudson jobs easily exclude that?
 
 
Between gcc and gcc-4.5 we are stuck for now.
gcc-4.5 works a lot and also definitely fails some.
In particular SPARC32_SOLARIS/SOLgnu/SOLsun fail right after throwing an exception.
SPARC64_SOLARIS has at least a small problem.
I'm not sure if there are problems beyond those.
 
 
Certainly if you want to "cherry pick" off a few files here and there, there is definitely opportunity.
I'm not sure if a few files here and there matter though.
 
 
m3-pkgtools presently isn't built for example.
dll2lib or whatever isn't worth anything these days.
 
 
The old m3gc-simple and m3gc-enhanced are dead.
 
 
I like a source control to preserve record of deleted stuff though.
 
 
 - Jay

 
> Date: Fri, 20 Aug 2010 16:15:36 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> CC: m3-support at elego.de
> Subject: [M3devel] Hudson setup and M3 repository, was: Re: VM for I386_NETBSD Hudson
> 
> Quoting Jay K <jay.krell at cornell.edu>:
> 
> > New Hudson node.
> > A VM running on MacBook.
> >   We'll see if it stays on and if the network works.
> 
> For your information
> 
> It seems we have crossed the acceptable load boundary for our hosted
> server birch.elegosoft.com recently. The main problem seems to be
> I/O caused by lots of concurrent CVS checkouts and updates in combination
> with internal backup, which make other services like HTTP unresponsive and
> unusable.
> 
> As far as I can see there is no easy short-time solution. We are going
> to find a new and more efficient home for our web services anyway in the
> fall, but it may be that we will have to limit the number of concurrent
> CVS accesses or Hudson job executions (including clients) for some time.
> 
> I'm currently also investigating if we can easily move to another
> (virtual) host or setup a proxy to improve matters. Both will need
> some migration on client sides.
> 
> I'll keep you informed what way we choose to resolve this problem.
> 
> It will help if you don't check in lots of small changes, but complete
> reasonable change sets.
> 
> It would also help if we could reduce the size of the repository again,
> especially in the gcc and gdb structures. If there is dead content
> that we don't really need, we might move it to another access path for
> some time.
> 
> Thanks in advance for your understanding and cooperation.
> 
> Please stay calm and continue to enjoy the flight ;-)
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100821/e76f74f1/attachment-0002.html>