Will "updates" get rid of files that got deleted from the repository? I don't like not having an accurate BOM. I want to know every file and what version of that file makes up my build. When I remove the directories and re-check my files out every time, I'm afforded the abiility to keep an accurate BOM and know that the BOM represents the product exactly. Otherwise, what confidence can I lend the customer that I know what I delivered to them?
________________________________ From: David Weintraub <qazw...@gmail.com> To: Ant Users List <user@ant.apache.org> Sent: Monday, June 1, 2009 9:19:16 AM Subject: Re: Use of Sleep On Mon, Jun 1, 2009 at 10:39 AM, Eric Fetzer <elstonk...@yahoo.com> wrote: > A good piece of the time, David, is allocated to check out of A LOT of > code. It also ftp's some very large files over a WAN. As I take over these > builds, I will be digging further in where all the time is going, but for > now, I'm just trying to get rid of totally unnecessary aspects of the build. I normally don't have Ant do my checkouts since you first have to checkout the build.xml file to do the initial checkout. We use Hudson for our continuous integration, and Hudson handles the checkouts for us. That way, I don't even have to define a checkout task in our build.xml file. (See < http://hudson.dev.java.net/>). You might want to switch from checkouts to updates since updates only update changed files, and don't checkout everything from scratch again. There are specific Ant checkout tasks for various version control systems, but I usually don't find them any faster than <exec>. Unless the <exec> task runs in the background (spawn="true"), it should wait for the <exec> task to complete. That means you shouldn't be having <sleep> tasks to wait for the checkout to complete. You normally run an <exec> task in the background when you're doing things like starting up a server, so you can run your tests. Otherwise, the default is to wait for the <exec> command to complete. BTW, there is a "timeout" parameter for the <exec> task that can help kill an otherwise lollying program, but it has a bit of trouble on Windows sytems. Best of luck speeding up your build. When I first got to my current job, builds took 30+ minutes to complete. I rewrote the build.xml file from scratch, and speeded it up to only "12 minutes". Meanwhile, we've pulled projects out of our main build, and each one of these build in under 2 or 3 minutes. The "big" project still takes about 9 minutes to build. Not where I'd like it, but much better than it was before. My experience shows that when builds take forever, developers simply don't test as well, and your code gets sloppier. -- David Weintraub qazw...@gmail.com
