I refactored the tests and save 8 MB, now using 7.8 MB. The changes have been commited.
Renaming will be done next week since I am out of time now Cheers christian Daniele Romagnoli writes: > On Fri, May 30, 2008 at 3:04 PM, Andrea Aime <[EMAIL PROTECTED]> wrote: > >> Christian Müller ha scritto: >> >>> Some questions: >>> 1) >>> Should I rename gt-imagemosaicJDBC to gt-imagemosiac-jdbc ? >>> >> >> This would be consistent with the other modules, so it's a good idea. > > > A small trivial note to avoid misunderstandings: we are talking about the > directory name within the physical svn repo. (As suggested here: > http://docs.codehaus.org/display/GEOT/5.2+Naming+Conventions) > > Since actually it is imagemosaicJDBC you can rename it as imagemosaic-jdbc. > (Note that there aren't directories starting with "gt-"). > > >> >> >> 2) For testing I decided to use 3 pyramids, the third pyramid contains >>> only 1 image. The biggest dir contains the tiles for the original image, >>> using 9.6 MB. The whole src dir needs 16 MB. I found some modules which >>> have equal size, e.g widgets-swing-pending needs about 15 MB, or the ogc >>> module. >>> >> >> Wow, this is bad. How can widgets-swing-pending need that much data? >> Are you sure you're not including in your size count stuff that is >> generated during the build? >> >> Please avoid that, you don't need that much data. You can make a pyramid >> we a few hundreds of kilobytes, size does not matter for unit testing, >> and for performance testing, the current 12MB are not enough anyways. >> >> The ideal (but this is more work, so nobody is asking you to do so) would >> be to generate your test data on the fly. I mean, you don't really >> need a specific image content, so you can just generate buffered images on >> the fly, draw a number or something inside of them, and save them on the >> disk. >> >> The tiles for itself will not change. I know the binary file problem from >>> CVS assuming there are the same problems with SVN. Since mosaicing and >>> selecting the correct pyramid is the key feature, I need these images for >>> testing. >>> >> >> The problem is not about how svn handles svn data, but put yourself >> in the pants of someone that has to check out geotools from a country >> with slow internet connection. Moreover, I believe there are performance >> issues in svn when the repository becomes too big. >> >> Cheers >> Andrea >> > > Cheers, > Daniele > > -- > ------------------------------------------------------- > Eng. Daniele Romagnoli > Software Engineer > > GeoSolutions S.A.S. > Via Carignoni 51 > 55041 Camaiore (LU) > Italy > > phone: +39 0584983027 > fax: +39 0584983027 > mob: +39 328 0559267 > > > http://www.geo-solutions.it > > ------------------------------------------------------- ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
