On Thu, Aug 03, 2006 at 01:13:22PM +0200, Francesco P. Lovergine wrote:
Markus asked me to report the list about some ideas I have...
Well, a CVS repo could be easily converted to a SVN one by cvs2svn, subversion
is currently the mainstream for a cetralized SCM. Honestly, CVS has
a series of defects for management, maybe it's time to use a more
advanced tool, without loosing past history.
Yes, I agree. I have recently migrated my own CVS (was running
for several years and quite fat) to SVN with cvs2svn. No big deal.
SVN would finally offer the possibility to create a GRASS Addon
repository with granular access rights.
It is also well integrated
with Trac which is a very nice bug tracker in respect with WebRT. That
could be a major pain for migration, anyway.
RT is pretty limited. We observe that developers don't like/use it.
This is obviously bad. In particular, the lack of patch support
(which is nice in trac) is a major pain.
Ideas?
The OSGeo foundation considers to offer SVN/trac etc support for
foundation projects. This could be interesting since moving bugs
among projects will (hopefully) be possible. Example: if an apparent
GRASS bug turns out to be a GDAL bug, we just move it there. No need
to write everything again. Also code leverage will be simplified
(no need to reinvent the wheel for many GIS tasks given the same
programming language is used).
PS: did the Google Summer of Code be considered for sponsored students
efforts about grass activities? I think grass is eligible as mentor for
that... The new year is not so far, indeed 
Good point!
Markus
Markus Neteler wrote:
The OSGeo foundation considers to offer SVN/trac etc support for
foundation projects. This could be interesting since moving bugs
among projects will (hopefully) be possible. Example: if an apparent
GRASS bug turns out to be a GDAL bug, we just move it there. No need
to write everything again. Also code leverage will be simplified
(no need to reinvent the wheel for many GIS tasks given the same
programming language is used).
Markus / GRASS developers,
I think the general intention was to maintain a distinct bug database
instance for each project, which would mean we can't easily reassign
bugs between project within a single database.
I will say, I found it quite helpful having various projects
(ie. gdal, libtiff, libgeotiff, proj.4) all in the same bug database
at remotesensing.org for exactly the reason you indicate. I just
don't think we will get that benefit on OSGeo unless we make a
particular effort to do so.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGF, http://osgeo.org
GRASS developers should consider also the use
of GIT, the content tracker currently in use
by the Linux kernel community. Currently the
Xorg source code is managed with git also.
Indeed i am tracking the CVS repository with
GIT in my laptop, and there is no pain at all.
Take a look at:
http://www.kernel.org/pub/software/scm/git/docs/
http://www.kernel.org/pub/software/scm/cogito/README
And the CVS migration
http://www.kernel.org/pub/software/scm/git/docs/cvs-migration.html
Of course is packaged in debian
http://packages.debian.org/unstable/devel/git-core
Best Regards
2006/8/4, Markus Neteler <neteler@itc.it>:
On Thu, Aug 03, 2006 at 01:13:22PM +0200, Francesco P. Lovergine wrote:
Markus asked me to report the list about some ideas I have…
Well, a CVS repo could be easily converted to a SVN one by cvs2svn, subversion
is currently the mainstream for a cetralized SCM. Honestly, CVS has
a series of defects for management, maybe it’s time to use a more
advanced tool, without loosing past history.
Yes, I agree. I have recently migrated my own CVS (was running
for several years and quite fat) to SVN with cvs2svn. No big deal.
SVN would finally offer the possibility to create a GRASS Addon
repository with granular access rights.
It is also well integrated
with Trac which is a very nice bug tracker in respect with WebRT. That
could be a major pain for migration, anyway.
RT is pretty limited. We observe that developers don’t like/use it.
This is obviously bad. In particular, the lack of patch support
(which is nice in trac) is a major pain.
Ideas?
The OSGeo foundation considers to offer SVN/trac etc support for
foundation projects. This could be interesting since moving bugs
among projects will (hopefully) be possible. Example: if an apparent
GRASS bug turns out to be a GDAL bug, we just move it there. No need
to write everything again. Also code leverage will be simplified
(no need to reinvent the wheel for many GIS tasks given the same
programming language is used).
PS: did the Google Summer of Code be considered for sponsored students
efforts about grass activities? I think grass is eligible as mentor for
that… The new year is not so far, indeed
Good point!
Markus
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev
–
Patricio Toledo Peña
Dpto. de Geofísica - Universidad de Chile
Blanco Encalada 2002-Casilla 2777
Santiago-Chile