One thing we can do to help Martin is review new modules and patches - duplicating test-data functionality would be a down check for example ...
However noticing after the fact is kind of too late as far as the size of the svn repo goes. I wonder if we can set any triggers on svn to not let files over 50k be committed in any other path then **/sample-data/** ? Another idea would be to set up a maven plug-in that can fetch the larger sample data from a website (I think GeoServer did something like this for their configurations - talk to Justin). With respect to people contacting you about the sample-data module: review the wiki page for test data in the developers guide; and perhaps list your contact details (and a sample email to yourself requesting the addition of test data). > The following file has been added recently on the 2.3 branch: > > ext/coverage_development/imageio/asciigrid/test/org/geotools/gce/imageio/asciigrid/test-data/spearfish.asc.gz > > Which duplicate the two files already present there: > > ext/coverage_development/imageio/customstreams/test/it/geosolutions/imageio/stream/test-data/spearfish.asc.gz > module/sample-data/src/org/geotools/test-data/shapes/spearfish_dem.asc.gz > > So we have 3 copies of an identical 285 kb file. Two of them are straight > "svn > add" (not "svn copy"), which is one too much. Even in the case of the recent > commit, while "svn copy" is cheap for SVN, it will have a cost on the > download > size of geotools release. > > Our SVN repository is gigabytes big according emails from our administrator, > and > this size is mainly caused by test data (duplications and huge files like > http://jira.codehaus.org/browse/GEOT-794) > > The "module/sample-data" module was created as an attempt to avoid this > problem > in the future (since we can't really change what is already in SVN history) > and > it already contains the "spearfish.asc.gz" file since January (actually named > "spearfish_dem.asc.gz" in "module/sample-data", but I have no objection to > rename it). Maybe this module is not publicized enough, or maybe it is not > useable enough, it which case I can volunter for improving its API if it can > favor more data reuse. But it would be nice if we could try to share test > data > more... > > Regards, > > Martin > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
