Sorry, I forgot to mention: this is ChiliProject release 2.0.0 .

Could you post your ruby, rubygems, rake and rack versions please?

Hello, thank you for getting back to me! Here's some more info:

$ rvm list

rvm rubies

=> ree-1.8.7-2011.03 [ i386 ]

$ ruby -v
ruby 1.8.7 (2011-02-18 patchlevel 334) [i686-linux], MBARI 0x8770, Ruby Enterprise Edition 2011.03

$ gem search rack

• LOCAL GEMS ***

rack (1.1.2, 1.0.1)

$ gem search rake

• LOCAL GEMS ***

rake (0.9.2, 0.8.7)

$ rake --version
rake, version 0.9.2

I forgot to include my gem version:

$ gem -v
1.6.2

Mmh, I don't really see anything wrong. Have you tried RAILS_ENV="development" rake redmine:migrate_from_trac instead of your command?

So here's what I'm running, from start to finish. On the db server:

On db server:
$ mysqladmin create chiliproject_dev # with correct credentials in config/database.yml

On web server:
$ cd chiliproject-2.0.0
$ rake generate_session_store
$ RAILS_ENV=development rake db:migrate
$ RAILS_ENV="development" rake redmine:migrate_from_trac
Migrating components....................
Migrating milestones........................................
Migrating custom fields
Migrating tickets.rake aborted!
TracMigrate is not missing constant TracTicketChange!

Tasks: TOP => redmine:migrate_from_trac
(See full trace by running task with --trace)

Scott, there's already an issue open regarding improvements to the Trac importer: #484, I don't think your issue is the same though. I also just realized that we're in the forums and not in an issue, could you please open a new one with a short description of your issue + the version info you already posted and here as well as a link to here?

As discussed on IRC: I'd need a dump of a Trac db to try to reproduce this, preferably as sqlite3, mysql or postgresql would work too. Alternatively, maybe Eric could take care of this issue as he already has a Trac dump (see #484).

Hi,

as I wrote yesterday to ticket #516 concerning this thread, the above mentioned bug is fixed by adding a missing scope (see my patch in ticket #516).

BUT:

Currently I'm struggling with a next error complaining about unknown attribute: created_on during the import of the tickets/issues :-(

Importing the milestones worked flawlessly and the first ticket, too. But during processing the first ticket/issue the migrate script aborts :-(

I'm not a Ruby developer, but willing to bugfix or even to help fixing that issue.

If possible I'll try to build a Trac DB dump (the problem currently is not to disclose high sensitive company data).

My test environments were:

• Ruby 1.8.7
• Gems 1.3.7
• MySQL 5.1
• RedMine 2.1.1 stable
• Gems:actionmailer (2.3.12) * actionpack (2.3.12) * activerecord (2.3.12) * activeresource (2.3.12) * activesupport (2.3.12) * bundler (1.0.18) * coderay (0.9.8) * columnize (0.3.4) * daemon_controller (0.2.6) * edavis10-object_daddy (0.4.3) * fastthread (1.0.7) * i18n (0.4.2) * linecache (0.46) * mocha (0.9.12) * mysql (2.8.1) * mysql2 (0.2.11) * passenger (3.0.8) * pg (0.9.0) * postgres (0.7.9.2008.01.28) * rack (1.1.2) * rails (2.3.12) * rake (0.9.2) * rbx-require-relative (0.0.5) * rdoc (3.9.2) * ruby-debug (0.10.4) * ruby-debug-base (0.10.4) * ruby-openid (2.1.8) * rubytree (0.5.3) * shoulda (2.10.3)

The Trac environment consists of a local copy of the trac dir and a remote PostgreSQL database.

Has anyone a hint for me where to search further or what I can test?

My problem:

I MUST solve the migration within two days - which are already spent for debugging and struggling with the migration :-( :-(

Can ANYONE help us PLEASE?

Otherwise I MUST switch back to Trac, if I won't be able to get the ChiliProject server running within this week - our management is even thinking about keeping Trac for ever :-( :-( :-(

ciao,
Chris

Chris Dähn wrote:

Currently I'm struggling with a next error complaining about unknown attribute: created_on during the import of the tickets/issues :-(

Can you please provide a stack trace? (run the rake task with --trace for more info)

Hi,

sorry I only posted the trace inside #516 - here the output:

Migrating components........
Migrating milestones...........................
Migrating custom fields...........
Migrating tickets.rake aborted!
unknown attribute: created_on
/usr/lib/ruby/gems/1.8/gems/activerecord-2.3.12/lib/active_record/base.rb:2918:in `assign_attributes'
/usr/lib/ruby/gems/1.8/gems/activerecord-2.3.12/lib/active_record/base.rb:2914:in `each'
/usr/lib/ruby/gems/1.8/gems/activerecord-2.3.12/lib/active_record/base.rb:2914:in `assign_attributes'
/usr/lib/ruby/gems/1.8/gems/activerecord-2.3.12/lib/active_record/base.rb:2787:in `attributes='
/usr/lib/ruby/gems/1.8/gems/activerecord-2.3.12/lib/active_record/base.rb:2477:in `initialize'
/opt/chiliproject/lib/tasks/migrate_from_trac.rake:488:in `new'
/opt/chiliproject/lib/tasks/migrate_from_trac.rake:488:in `migrate'
/usr/lib/ruby/gems/1.8/gems/activesupport-2.3.12/lib/active_support/ordered_hash.rb:115:in `each'
/usr/lib/ruby/gems/1.8/gems/activesupport-2.3.12/lib/active_support/ordered_hash.rb:115:in `each'
/opt/chiliproject/lib/tasks/migrate_from_trac.rake:483:in `migrate'
/usr/lib/ruby/gems/1.8/gems/activerecord-2.3.12/lib/active_record/batches.rb:26:in `find_each'
/usr/lib/ruby/gems/1.8/gems/activerecord-2.3.12/lib/active_record/batches.rb:26:in `each'
/usr/lib/ruby/gems/1.8/gems/activerecord-2.3.12/lib/active_record/batches.rb:26:in `find_each'
/usr/lib/ruby/gems/1.8/gems/activerecord-2.3.12/lib/active_record/batches.rb:66:in `find_in_batches'
/usr/lib/ruby/gems/1.8/gems/activerecord-2.3.12/lib/active_record/batches.rb:25:in `find_each'
/opt/chiliproject/lib/tasks/migrate_from_trac.rake:458:in `migrate'
/opt/chiliproject/lib/tasks/migrate_from_trac.rake:762
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/task.rb:205:in `call'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/task.rb:205:in `execute'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/task.rb:200:in `each'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/task.rb:200:in `execute'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/task.rb:158:in `invoke_with_call_chain'
/usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/task.rb:151:in `invoke_with_call_chain'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/task.rb:144:in `invoke'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/application.rb:112:in `invoke_task'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/application.rb:90:in `top_level'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/application.rb:90:in `each'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/application.rb:90:in `top_level'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/application.rb:129:in `standard_exception_handling'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/application.rb:84:in `top_level'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/application.rb:62:in `run'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/application.rb:129:in `standard_exception_handling'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/application.rb:59:in `run'
/usr/lib/ruby/gems/1.8/gems/rake-0.9.2/bin/rake:32
/usr/bin/rake:19:in `load'
/usr/bin/rake:19
Tasks: TOP => redmine:migrate_from_trac

Any hints are appreciated.

ciao,
Chris

PS: Besides at first start I thought this could be an issue of the german umlauts in the ticket's subject - but experimenting with clean english subjects and different charsets didn't change anything.

Oh, hadn't looked there, sorry.

I just had a look at the rake task, and it re-creates the issue history "by hand", the way issue history is stored has changed though (model- and data-wise), so it won't work unless someone rewrites that part of the rake task.

Can you open a new issue for this one (it's not the same problem as #516) and assign it to me? I'll try to have a look. Can you provide me with at least the schema of your Trac DB?

Hi,

if the way the data are stored changed - is there the possibility to use an old ChiliProject/RedMine version to run the migration and afterwards upgrading CP/RM?

The rewriting sounds good, but will take much time to realize. Of course I can provide you a (censored) Trac db dump to simplifiy the testing - is PostgreSQL ok or do you need it as MySQL/SQLite?

Thanks for your help in advance! :)

ciao,
Chris

Chris Dähn wrote:

if the way the data are stored changed - is there the possibility to use an old ChiliProject/RedMine version to run the migration and afterwards upgrading CP/RM?

Yes, importing to ChiliProject 1.5.2 and upgrading to latest should work OK.

The rewriting sounds good, but will take much time to realize. Of course I can provide you a (censored) Trac db dump to simplifiy the testing - is PostgreSQL ok or do you need it as MySQL/SQLite?

Not sure I'd need it anyway as the DB format doesn't seem to have changed in Trac… Forget about it for now, I'll ask again if I hit a blocker.

Ok, I'll try importing with CP 1.5 - would be great, if that works.

Thanks for your help Felix!

Viele Grüße aus dem Hohen Norden,
Chris

Update: I ran the migration based on ChiliProject 1.5.2 and it succeeded! :) Just the Wiki stuff is partly destroyed / not imported correctly. But that's just a part of handcraft :D

ciao,
Chris