fluid-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] Migration of services


From: Pedro Lopez-Cabanillas
Subject: Re: [fluid-dev] Migration of services
Date: Tue, 18 May 2010 11:11:16 +0200
User-agent: KMail/1.9.6 (enterprise 20070904.708012)

On Tuesday, May 18, 2010, Elimar Green wrote:
> There is no way to export/import the
> tickets in a semi-automated fashion and it wouldn't retain any of the user
> account info anyways, since accounts will be SourceForge accounts and not
> the original ones in the FluidSynth Trac system.

There isn't an "import into trac hosted app" functionality in SourceForge, 
according to some reports around the net:
http://www.mail-archive.com/address@hidden/msg18109.html
https://sourceforge.net/apps/trac/sourceforge/ticket/1198
https://sourceforge.net/apps/trac/sourceforge/ticket/9218

The problem may be that SourceForge doesn't allow direct access to the Trac 
database, or Trac plugins managing the ticket data. Anyway, what's the format 
of your backup data, and which database was used in the former server?

> Any thoughts?  I think these are the options:
> - Find another place to host the original FluidSynth Trac install (any
> offers?)
> - Host SVN on the Trac host
> - Host SVN on Savannah or SourceForge and periodically sync it to the Trac
> host
> - Host Trac on SourceForge and manually re-create tickets, losing much
> history info, Ticket CCs, time consuming to re-enter data, etc.

Another option is to forget about the old trac tickets, and trac SVN sync. 
Maybe you can convert the existing tickets in text format, and let everyone 
to create them again, one by one. About the SVN integration, SF.net offers a 
SVN web browser and there are RSS feeds offering the project's activity. Not 
a big loss.

I would like to advice against using another random hosting service, risking 
to lose control again in the future. It's better to be stuck in some 
stablished service provider like Sourceforge or Savannah, with their 
limitations.

Regards,
Pedro



reply via email to

[Prev in Thread] Current Thread [Next in Thread]