... which is relatively speedy (for Python Gump). I think the multi-threaded CVS|SVN updates have taken a bunch of the idle latency out of the equation, so cost Brutus little & saved a bunch.
Of course, I've long since forgotten how long traditional takes to do a run, but comparing against previous Python Gump, this doesn't suck. See: "Dates/Times" on http://brutus.apache.org/gump/public/. FWIIW: I've not experimented with # of threads (this used 1 main thread, 5 background workers) to see which is optimal, nor counted how many times [if any] the main builder thread had to stop and do the update.] (One day (a ways off) I hope to multi-thread the project builds, but that is a tad more complicated due to inter-dependencies. Also, I am going to crack repository work first. FWIIW: We are generating/publishing jars to a repo, just not making it public yet, pending legality checks.) regards Adam -- Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise Try Sybase: http://www.try.sybase.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
