Forum: open-discussion

Monitor Forum | Start New Thread Start New Thread
RE: 5.3 Several problems during db ugrade with svntrackerToScmhookCommitTrackerMigra [ Reply ]
By: Peter Katzmann on 2014-06-06 14:08
[forum:716]
Probably i could share my migration script,.

But it's no trivial task to convert from such an old base and i can not give any support to this.

Because there are plenty steps involved i have to polish the "documentation"

RE: 5.3 Several problems during db ugrade with svntrackerToScmhookCommitTrackerMigra [ Reply ]
By: Franck Villaume on 2014-06-06 13:50
[forum:715]
would you mind to share your migration script ? I assume some other gforge-as users will be interested.

RE: 5.3 Several problems during db ugrade with svntrackerToScmhookCommitTrackerMigra [ Reply ]
By: Franck Villaume on 2014-06-06 13:49
[forum:714]
5.3.1 (debian packages are available in unstable I presume) is now available which included some scmhook fixes.
warning the group_get_object_by_publicname does not include your proposed fix. I opened a bug about that. See https://fusionforge.org/tracker/?func=detail&atid=105&aid=687&group_id=6

RE: 5.3 Several problems during db ugrade with svntrackerToScmhookCommitTrackerMigra [ Reply ]
By: Peter Katzmann on 2014-06-06 10:25
[forum:710]
Sure i can, it is an gforge-as from 2008.
But this was not the root of the problem because my conversion script worked well with migration to 5.2. Now we are in the final process of switching from the old gforge as to 5.3 and i found the described problems, but only in this conversion script, everything else works well

peter

RE: 5.3 Several problems during db ugrade with svntrackerToScmhookCommitTrackerMigra [ Reply ]
By: Franck Villaume on 2014-06-06 10:01
[forum:709]
can you tell us what you call "old gforge" ?
what version ?

5.3 Several problems during db ugrade with svntrackerToScmhookCommitTrackerMigra [ Reply ]
By: Peter Katzmann on 2014-06-06 08:52
[forum:708]
Hello,
i encountered several problems with
20130531-svntrackerToScmhookCommitTrackerMigration.php
during upgrading a old gforge database to fusionforge on a debian install.

Follwing problems arose:
At first the script complains about not installed plugin.
The problem comes from the variable $gfplugins which is empty.
I resolved this due temporary editing common/include/env.inc.php
changing the last lines to:

//if( !ini_set('include_path', $include_path ) && !set_include_path( $include_path )) {
$gfcommon = $fusionforge_basedir.'/common/';
$gfwww = $fusionforge_basedir.'/www/';
$gfplugins = $fusionforge_basedir.'/plugins/';
//} else {
// $gfcommon = '';
// $gfwww = '';
// $gfplugins = '';
//}

The next problem was that i got complains about undefined variable pluginScmHook.
I don't know why, worked around this with reinitialize the variable during each loop.

After this i got a error about projectObject is not a object.
This problem arose because i had project names in the database with & inside the name.
In common/include/Group.class.php there is a escaping of special chars with htmlspecialchars
. But this routine is buggy because it looks stupidly for characters and doesn't analyze if this already a escaped char :(
So i changed it in the way to first expand the name and then escape it:
function group_get_object_by_publicname($groupname) {
$res = db_query_params('SELECT * FROM groups WHERE lower(group_name) LIKE $1',
array(htmlspecialchars(html_entity_decode(strtolower($groupname)))));
return group_get_object(db_result($res, 0, 'group_id'), $res);
}

The last thing was and database exception due to referential constraints of group_plugin to the plugin_name table.
I resolved this with additon of
$res = db_query_params("DELETE from group_plugin where plugin_id = (select plugin_id from plugins where plugin_name='svntracker')",array());

after the conversion loop

peter