Matthew Mastracci wrote:
Bonus points if you can recognize that you only need to recurse past a
"blah*" or "bar*" node.
I imagine the correct solution would involve some sort of tree
structure in memory that gets build from the components of all the
patterns and represents the ideal scanning strategy for the entire
set. Dealing with patterns like "foo/**/bar/blah.cs" would be an
interested problem as well.
My explanation is all over the place, but I guess my final point is
that the correct implementation is a Hard Problem and our current
solution is Good Enough(tm) for most people. ;)
For what it's worth, I just tried it with ant and NAnt, with the
following file:
<?xml version="1.0" encoding="iso-8859-1"?>
<project>
<target name="copy-results" >
<copy
todir="./results"
flatten="true"
failonerror="True">
<fileset dir="." > <!-- Change 'dir' to 'basedir' for NAnt -->
<include name="*/results/*results.xml" />
</fileset>
</copy>
</target>
</project>
The only difference between the ant and NAnt versions is the one change
indicated.
The ant version ran in about 8 seconds. The NAnt version took 53
seconds. I ran each twice in a row and used the second set of numbers,
to avoid discrepencies due to the disk cache. (Yes, I know it's not
great performance testing.) So I wonder if they're using a better
algorithm or have tuned it for different purposes?
PS The tests should be there, anyway. One of the important points of
agile methodologies is that a comprehensive test suite makes it much
cheaper to fix design problems.
The DirectoryScanner code is one of the oldest pieces of NAnt and has
a lot of black-box testing. :) While the tests might indicate that
the code is correctly passing the tests, it needs a lot more white-box
testing to make sure that we're
Warning, QA Engineer diversion: Strictly speaking, it doesn't have to be
white-box testing. The real requirement is speed, not whether a
directory gets opened once or ten times, and putting performance tests
in place doesn't require knowing anything about the insides of the program.
The biggest reason is that NAnt 0.85 is getting very close to a
release and any major change could push the release even further
back. Past the release, I don't think anyone will mind a little
refactoring.
I quite agree. I don't think any changes should be made to CVS right
now unless there's first a bug in the bug database that it addresses, or
it's a doc fix, or it's a test. (Ooops - I entered this as a bug, as
per Gert's suggestion. But it's not significant enough to be scheduled
for 0.85.)
Gary
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Nant-users mailing list
Nant-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-users
