Forum: helpMonitor Forum | Start New Thread
By: Franck Villaume on 2018-04-24 18:00
That is a good news! Well done!
Now you can apply update from beta2 to RC1 :-)
By: Graham Miller on 2018-04-23 04:03
With quite a journey I got the forge up and running with the old DB and (maybe) all the DB updates applied.
Running version 6.1.0beta2-1.201803251148
There was some selinux issues, some misunderstanding on my part, and a fair bit of manually applying SQL updates, and modifications to install-ng script.
I won't post the saga here ... its too big a story with a few stuff-ups on the way.
Thanks for your help.
By: Franck Villaume on 2018-04-06 08:55
|no impact. it's better that way.|
By: Graham Miller on 2018-04-06 07:28
Just had a thought.
I have cron and systasksd still disabled. Will that affect my attempting to run these scripts? It does not look like it from where I sit, but I just thought I'd ask?
By: Graham Miller on 2018-04-05 02:38
When running 20090507-install_workflow.php I get an error
[graham@jenshen2 db.511]$ sudo -u fusionforge php 20090507-install_workflow.php
PHP Fatal error: Call to undefined function db_query_params() in /usr/share/fusionforge/db.511/20090507-install_workflow.php on line 18
Can't find any logs for this one either.
A bit stuck now. Wish I could find the logs to see why these cli scripts are failing.
By: Graham Miller on 2018-04-05 02:30
About startpoint.php, I cannot run it from the db.511 directory OR the v6.1 db directory. They both give me the following errors:-
[graham@jenshen2 db.511]$ php startpoint.php
PHP Notice: Undefined variable: gfconn in /usr/share/fusionforge/db.511/startpoint.php on line 7
PHP Fatal error: Call to undefined function db_error() in /usr/share/fusionforge/db.511/startpoint.php on line 8
[graham@jenshen2 db]$ sudo -u fusionforge ./startpoint.php
PHP Notice: Undefined variable: gfconn in /usr/share/fusionforge/db/startpoint.php on line 27
PHP Fatal error: Call to undefined function db_error() in /usr/share/fusionforge/db/startpoint.php on line 28
[graham@jenshen2 db]$ php -v
PHP 5.4.16 (cli) (built: Mar 7 2018 13:34:47)
I have enabled development mode and turned on most of the debug variables, but I can't find where the log is?
There does not seem to be anything going to /var/log/fusionforge/ or /var/log/httpd/ or /var/log/messages.
Here is the config list:
$ sudo -u fusionforge forge_get_config list-all-variables-values
core/apache_auth_realm: SCM for FusionForge
By: Graham Miller on 2018-04-05 00:54
About v3.3 - I have not looked for v3.3 code, but it is mentioned in the v5.1.1 startpoint.php in the check_version() method. I do have a downloaded file in our archives:
I am happy to upload it or send it to you if you want it for your archives.
I ran the SELECT statement you suggested and it returns 0 rows. So I will run that script and see how it goes.
As for the database_changes table, I don't have one of those yet because I have not run startpoint.php so I will try to get that to run. Just have to decide on what is the start point.
According to the check_version() method, v4.8.2 is dated 20090402 so, even though I have gone past that date manually, I might set that as a startpoint then run the upgrade-db.php script to get to v5.1.1.
By: Franck Villaume on 2018-04-04 17:03
about 3.3: good to know. I'm always discovering things about FusionForge. Can you point me to the 3.3 source code?
about the 20090507-install_workflow.php script:
run the following SQL query on your database:
SELECT group_id, artifact_group_list.group_artifact_id, element_id, artifact_extra_field_elements.extra_field_id
FROM artifact_extra_field_list, artifact_extra_field_elements, artifact_group_list
AND artifact_group_list.group_artifact_id = artifact_extra_field_list.group_artifact_id
If this query returns 0 row, then you can run this script safelly.
If this query returns some rows, I've looked at the PHP code in the 6.1 branch, from my point of view, it should work as well.
About startpoint.php & upgradedb.php :
Did you insert into database_changes all the scripts that you run successfully? You have to.
Extract from the content of my database_changes:
By: Graham Miller on 2018-04-04 13:48
Well now I have imported the old v4.5 database. Had to fix db object ownership to all fusionforge. It looks like I nearly have the DB at v5 but need some advice before trying the upgrade script in v6.1 (the orig installed ver).
I grabbed a v5.1.1 download and pulled the db/ directory to use on the v4.5 db. Copied to /usr/share/fusionforge/db.511/, cd into it, then tried the startpoint.php file but got errors and realised the structure in /common is different. Decided not to try that script.
So I went through, methodically, all the sql scripts from after v3.3 (yes there was mention of that version) and compared the DB (pgAdmin) to the effects of the upgrade statements. Got right up to v4.5 before finding any glaring differences. Applied the sqls in order until the end of 2009, where I got to a php script that needed to instantiate fusionforge objects.
It looks like this should be run before tackling the v6.1 upgrade.php script. The earliest upgrade sql script in v6.1 is 20100308-drop-forum-attachment-type.sql which, in the v5.1 upgrade scripts is the next task after the install_workflow.php.
Here are the require lines at the top of the install_workflow file:
Do you think that v6.1 will instantiate those class well enough to allow the workflow to the installed? I just want to check before running this on the database I have so carefully groomed.
Yes I have a backup but would prefer to reduce the manhours going into this by checking first <grin>.
Hope you know the answer to this.
By: Franck Villaume on 2018-03-01 15:12
that is correct:
here is the link to upgrade scripts to 5.0.3:
And you are going to run into trouble :-)
Please post your feedback/errors here. I will try to help you to debug.
By: Graham Miller on 2018-03-01 10:45
Thanks for the good info Franck.
I do not have the source code of this old version so am only guessing about the version number. Shame its not stored in the DB somewhere.
I found various versions of gforge in our "download repo" archive, and guessed the version based on the file timestamp. Someone must have miss-named the file I guess.
So you are probably right about the 4.5.3, as there does not seem to be any downloads after that one.
I understand your instructions OK, so what I need to find is a version 5x of gforge/fusionforge to get the upgrage scripts from there and apply them to the revived archive version of the DB, correct?
By: Franck Villaume on 2018-03-01 08:00
how I would do it:
- install a brand new fusionforge, including the database.
- stop all fusionforge services (apache + systasksd + cron)
- drop the brand new fusionforge database
- create an empty fusionforge database
- inject your database dump
- looks for migration script to do an incremental migration: See https://scm.fusionforge.org/anonscm/gitweb?p=fusionforge/fusionforge.git;a=heads to get migration scripts for the correct version.
The incremental migration objective is to transform progressively your data into the correct format.
About the gforge version you have:
v3.3 does not exist as far as I know.
Ten years ago: I bet on 4.5.3 or a little bit above. Looking at the source code could help you to identify the version.
FusionForge 6.1 migration script works correctly if your database is 4.8.50 compatible. Therefore you have to upgrade your database from 4.5 to 5.0.
Looks at this page as well:
Hope this help.
Franck aka nerville
By: Graham Miller on 2018-03-01 00:30
I have the PostgreSQL dump of the database for the gforge installation that managed a software development job and was moth-balled 10 years ago. I would like to get this project data into a new forge based on fusionforge. Will this be possible?
I do not have the source code from the live server at the time, but from the software packages downloaded around that time it is either gforge 3.3 or 4.5.3. My best guess would be gforge 3.3
There is custom data (what looks like project related data) in the following tables:-
-- the above seem to be in the latest stable fusionforge
-- these seem to be orphans
(I left out the stats* tables that had data but I don't care about them)
So I am guessing:-
- install a new fusionforge installation
- adapt the dump "COPY ... FROM stdin" sql scripts to suit fusion DB tables
- remove create table seq etc from DB dump file
- remove unwanted data from DB dump file
- run the import script.
So will this work? Am I on the right track?