[ka-Map-dev] osgeo hosting of svn/trac

Daniel Morissette dmorissette at mapgears.com
Sat Mar 24 08:22:16 EST 2007

Paul Spencer wrote:
> OSGeo has indicated that they are willing to provide SVN/Trac services 
> to the ka-Map project.  I will let Lorenzo lead from here since this is 
> his initiative, but I personally support the move to SVN because I find 
> it much easier to work with and I am impressed with the tight 
> integration of Trac with SVN.

My experience with SVN so far has been mostly frustrating, but since 
everybody tells me it's so much better than CVS I'll take your word for it.

I have to admit the Trac/SVN integration sounds cool.

> There are a lot of things to discuss concerning this:
> * moving the source code repository from MapTools CVS to SVN.  There are 
> some choices when we do this:
>   - use SVN only for new development, leave existing code in CVS
>   - use SVN for all existing source and new development (the intention 
> would be to preserve the history from cvs)
>   - don't move anything

OOpps.. I just replied to that question in my other email. Here it is 

If we move, then we should move 1.x to SVN as well, even if just to 
avoid the confusion of having two repositories.

Here is a possible transition scenario:

1- Give at least a few days of warning to all developers that the 
CVS->SVN move is coming so that they have time to plan their work around 
the migration, commit any edited file to CVS, etc.

2- Import the current CVS tree (including all history) in SVN

3- Create a 1.x branch in SVN

4- The SVN trunk becomes 2.x

> * moving issue tracking to Trac.  There are some choices here too:
>   - continue to use bugzilla (don't bother with Trac)
>   - start fresh in Trac (don't bring existing stuff across).  Bugzilla 
> ka-Map product would be left in place and closed for bug entry.
>   - attempt to bring all bug history into Trac.  Bugzilla ka-Map product 
> would be closed for bug entry and, if possible, deleted

My 0.02$ is to maintain all history if possible.

> * moving wiki to Trac.  There are some choices:
>   - Move the ominiverde wiki into Trac.  Trac is a wiki as well as an 
> issue tracking system.
>   - continue to use ominiverde wiki and use Trac only for issues

I have no preference on that front, as long as no documentation is lost.

> * moving ka-Map MapTools web site content into Trac ... I don't think we 
> should do this as we attract a lot of attention from people going 
> through MapTools ...

Fine with me.

Daniel Morissette

More information about the ka-Map-dev mailing list