From: Martin D. <mar...@ge...> - 2007-10-18 10:58:28
|
Should we move our GeoTools SVN to OSGEO infrastructure? We could take the opportunity for: * Separate GeoTools from uDig (right now they share the same SVN; GeoTools revision number increase when a commit is done in uDig and conversely. Backup is also bigger). * Strip from history some huge files that should never have been commited to the SVN. It should help to make backup smaller. Should we consider this issue as related to OSGEO graduation from incubation process? (i.e. move to OSGEO svn only when we graduated and/or completed the legal review process), or as a totally unrelated task that could be done at any time? Martin |
From: Andrea A. <aa...@op...> - 2007-10-18 12:34:44
|
Martin Desruisseaux ha scritto: > Should we move our GeoTools SVN to OSGEO infrastructure? We could take the > opportunity for: > > * Separate GeoTools from uDig (right now they share the same SVN; > GeoTools revision number increase when a commit is done in uDig > and conversely. Backup is also bigger). > > * Strip from history some huge files that should never have been > commited to the SVN. It should help to make backup smaller. > > > Should we consider this issue as related to OSGEO graduation from incubation > process? (i.e. move to OSGEO svn only when we graduated and/or completed the > legal review process), or as a totally unrelated task that could be done at any > time? Is there anyone knowing about OSGEO server reliability? So far the geotools svn server does not have exactly an excellent record for being online (it is offline one a week or every other week) but we never lost data and refractions admin is quite responsive in office hours. Before taking the trouble to switch I would like to make sure we switch to a better solution (faster, more reliable) :) Cheers Andrea |
From: Martin D. <mar...@ge...> - 2007-10-18 13:29:04
|
Andrea Aime a écrit : > Is there anyone knowing about OSGEO server reliability? > So far the geotools svn server does not have exactly an excellent record > for being online (it is offline one a week or every other week) but > we never lost data and refractions admin is quite responsive in office > hours. > Before taking the trouble to switch I would like to > make sure we switch to a better solution (faster, more reliable) :) Refractions guys could tell more, but one issue is that current server is still running Subersion 1.1.4, while latest version is 1.4.5. The 1.1 branch is not supported anymore for years. If I remember correctly, Paul told me that some configuration issue related to the Linux distribution used on that particular server make very hard to update Subversion without updating the whole system. I'm also making the assumption that a trimmed SVN repository (with non-geotools history removed) may help to speed up some svn operations (maybe the ones involving history scans like "svn log"), but this is just an assumption. An alternative is to move on SourceForge SVN, since we still have a GeoTools project on SourceForge. It would be consistent with our mailing-list adress. Martin |
From: Jody G. <jga...@re...> - 2007-10-18 16:20:40
|
Martin Desruisseaux wrote: > Refractions guys could tell more, but one issue is that current server is still > running Subersion 1.1.4, while latest version is 1.4.5. The 1.1 branch is not > supported anymore for years. If I remember correctly, Paul told me that some > configuration issue related to the Linux distribution used on that particular > server make very hard to update Subversion without updating the whole system. > Not sure about that; let's ask ad...@re... for details? > I'm also making the assumption that a trimmed SVN repository (with non-geotools > history removed) may help to speed up some svn operations (maybe the ones > involving history scans like "svn log"), but this is just an assumption. > > An alternative is to move on SourceForge SVN, since we still have a GeoTools > project on SourceForge. It would be consistent with our mailing-list adress. > Bleck; I would much rather move to codehaus svn - they have been doing very well for geoserver; and we would have the added advantage of punting artifacts into their maven repository (which is already mirrored around the world). Compare as search for "geotools" to a search for "geoserver" here: - http://mvnrepository.com/ Cheers, Jody |
From: Paul R. <pr...@re...> - 2007-10-18 16:32:06
|
Just wait and move to osgeo. Why do two moves? P On 18-Oct-07, at 9:20 AM, Jody Garnett wrote: > Martin Desruisseaux wrote: >> Refractions guys could tell more, but one issue is that current >> server is still >> running Subersion 1.1.4, while latest version is 1.4.5. The 1.1 >> branch is not >> supported anymore for years. If I remember correctly, Paul told me >> that some >> configuration issue related to the Linux distribution used on that >> particular >> server make very hard to update Subversion without updating the >> whole system. >> > Not sure about that; let's ask ad...@re... for details? >> I'm also making the assumption that a trimmed SVN repository (with >> non-geotools >> history removed) may help to speed up some svn operations (maybe >> the ones >> involving history scans like "svn log"), but this is just an >> assumption. >> >> An alternative is to move on SourceForge SVN, since we still have >> a GeoTools >> project on SourceForge. It would be consistent with our mailing- >> list adress. >> > Bleck; I would much rather move to codehaus svn - they have been > doing very well for geoserver; and we would have the added > advantage of punting artifacts into their maven repository (which > is already mirrored around the world). > > Compare as search for "geotools" to a search for "geoserver" here: > - http://mvnrepository.com/ > > Cheers, > Jody |
From: Jody G. <jga...@re...> - 2007-10-18 16:17:27
|
We should only do this if we have the man power ;-) I am more concerned about gathering up people to fix the headers and run the providence review again (many of our module maintainers are not going to have a spare day to review their own module; and search and replace does not work for this sort of thing). Jody > Should we move our GeoTools SVN to OSGEO infrastructure? We could take the > opportunity for: > > * Separate GeoTools from uDig (right now they share the same SVN; > GeoTools revision number increase when a commit is done in uDig > and conversely. Backup is also bigger). > > * Strip from history some huge files that should never have been > commited to the SVN. It should help to make backup smaller. > > > Should we consider this issue as related to OSGEO graduation from incubation > process? (i.e. move to OSGEO svn only when we graduated and/or completed the > legal review process), or as a totally unrelated task that could be done at any > time? > > Martin > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Geotools-administration mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-administration > |