On Fri, May 30, 2008 at 3:04 PM, Andrea Aime <email@example.com
Christian Müller ha scritto:
This would be consistent with the other modules, so it's a good idea.
Should I rename gt-imagemosaicJDBC to gt-imagemosiac-jdbc ?
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-").
Wow, this is bad. How can widgets-swing-pending need that much data?
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.
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 problem is not about how svn handles svn data, but put yourself
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.
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.