GRASS developers should consider also the use <br>of GIT, the content tracker currently in use <br>by the Linux kernel community. Currently the<br>Xorg source code is managed with git also.<br><br>Indeed i am tracking the CVS repository with
<br>GIT in my laptop, and there is no pain at all.<br><br>Take a look at:<br><a href="http://www.kernel.org/pub/software/scm/git/docs/">http://www.kernel.org/pub/software/scm/git/docs/</a><br><a href="http://www.kernel.org/pub/software/scm/cogito/README">
http://www.kernel.org/pub/software/scm/cogito/README</a><br><br>And the CVS migration<br><a href="http://www.kernel.org/pub/software/scm/git/docs/cvs-migration.html">http://www.kernel.org/pub/software/scm/git/docs/cvs-migration.html
</a><br><br>Of course is packaged in debian<br><a href="http://packages.debian.org/unstable/devel/git-core">http://packages.debian.org/unstable/devel/git-core</a><br><br>Best Regards<br><br><div><span class="gmail_quote">
2006/8/4, Markus Neteler <<a href="mailto:neteler@itc.it">neteler@itc.it</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On Thu, Aug 03, 2006 at 01:13:22PM +0200, Francesco P. Lovergine wrote:
<br>> Markus asked me to report the list about some ideas I have...<br>><br>> Well, a CVS repo could be easily converted to a SVN one by cvs2svn, subversion<br>> is currently the mainstream for a cetralized SCM. Honestly, CVS has
<br>> a series of defects for management, maybe it's time to use a more<br>> advanced tool, without loosing past history.<br><br>Yes, I agree. I have recently migrated my own CVS (was running<br>for several years and quite fat) to SVN with cvs2svn. No big deal.
<br><br>SVN would finally offer the possibility to create a GRASS Addon<br>repository with granular access rights.<br><br>> It is also well integrated<br>> with Trac which is a very nice bug tracker in respect with WebRT. That
<br>> could be a major pain for migration, anyway.<br><br>RT is pretty limited. We observe that developers don't like/use it.<br>This is obviously bad. In particular, the lack of patch support<br>(which is nice in trac) is a major pain.
<br><br>> Ideas?<br><br>The OSGeo foundation considers to offer SVN/trac etc support for<br>foundation projects. This could be interesting since moving bugs<br>among projects will (hopefully) be possible. Example: if an apparent
<br>GRASS bug turns out to be a GDAL bug, we just move it there. No need<br>to write everything again. Also code leverage will be simplified<br>(no need to reinvent the wheel for many GIS tasks given the same<br>programming language is used).
<br><br>> PS: did the Google Summer of Code be considered for sponsored students<br>> efforts about grass activities? I think grass is eligible as mentor for<br>> that... The new year is not so far, indeed :)<br>
<br>Good point!<br><br>Markus<br><br>_______________________________________________<br>grass-dev mailing list<br><a href="mailto:grass-dev@grass.itc.it">grass-dev@grass.itc.it</a><br><a href="http://grass.itc.it/mailman/listinfo/grass-dev">
http://grass.itc.it/mailman/listinfo/grass-dev</a><br></blockquote></div><br><br clear="all"><br>-- <br>Patricio Toledo Peña<br>Dpto. de Geofísica - Universidad de Chile<br>Blanco Encalada 2002-Casilla 2777<br>Santiago-Chile