On 2011-11-29, Emma Burrows wrote: > Thank you for the response. Sorry, I should probably have anticipated > that response by expanding more thoroughly on exactly what happens. :)
8-) > Actually, come to think of it, the date is probably a bit of a red > herring. I suppose what I really need is some process to say "this is > the last 'build version'" (a cache of checksums collected at a given > point in time for instance?), and then to say "copy over only the > files which aren't identical to the last 'build version'". This would > also allow for us having to re-run the CMS build more than once during > the week but still load all the files that changed since the last > milestone build as it were. You could copy the files that represent a version to some cache directory and use the different selector to select the files that are different from the ones inside the cache. The main difference between this approach and the modified selector would be the disk space required (full files rather than checksums are kept) but the speed is likely similar (you need byte-by-byte comparisons but don't calculate hashes). Another approach more in line with your original one is to explicitly set update to false on your modified selector during normal builds and set it to true when you actually deploy the files. This way modified files will always be treated as modified until you deploy them. Or you use different cache files for development and deployment (see the cache.cachefile parameters). Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@ant.apache.org For additional commands, e-mail: user-h...@ant.apache.org
