PgZilla 2.15 Migration - Mozilla

This is a discussion on PgZilla 2.15 Migration - Mozilla ; I have inherited a RedHat PgZilla 2.15 installation that I would love to migrate onto a current BugZilla. I have tried the rather hopefull direct upgrade, with simply installing 2.22 and running checksetup.pl on a copy of the database, but ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: PgZilla 2.15 Migration

  1. PgZilla 2.15 Migration

    I have inherited a RedHat PgZilla 2.15 installation that I would love
    to migrate onto a current BugZilla. I have tried the rather hopefull
    direct upgrade, with simply installing 2.22 and running checksetup.pl
    on a copy of the database, but this breaks with the errror:

    -- start --
    Checking for DBD::Pg (v1.31) ok: found v1.49
    Checking for PostgreSQL (v7.03.0000) ok: found v08.00.0800

    Adding new table attachments ...
    [Thu Sep 21 10:20:58 2006] checksetup.pl: NOTICE: CREATE TABLE will
    create implicit sequence "attachments_attach_id_seq1" for serial column
    "attachments.attach_id"

    Software error:


    DBD::Pg::db do failed: ERROR:  relation "attachments"
    already exists
    at Bugzilla/DB.pm line 513

    Bugzilla:B::_bz_add_table_raw('Bugzilla:B::Pg=HASH(0x9e95fd4)',
    'attachments') called at Bugzilla/DB.pm line 488
    Bugzilla:B::bz_add_table('Bugzilla:B::Pg=HASH(0x9e95fd4)',
    'attachments') called at Bugzilla/DB.pm line 335

    Bugzilla:B::bz_setup_database('Bugzilla:B::Pg=HASH(0x9e95fd4)')
    called at Bugzilla/DB/Pg.pm line 220

    Bugzilla:B::Pg::bz_setup_database('Bugzilla:B::Pg=HASH(0x9e95fd4)')
    called at ./checksetup.pl line 1601


    For help, please send mail to this site's webmaster, giving this error
    message
    and the time and date of the error.


    [Thu Sep 21 10:20:58 2006] checksetup.pl: DBD::Pg::db do failed: ERROR:
    relation "attachments" already exists
    [Thu Sep 21 10:20:58 2006] checksetup.pl: at Bugzilla/DB.pm line 513
    [Thu Sep 21 10:20:58 2006] checksetup.pl:
    Bugzilla:B::_bz_add_table_raw('Bugzilla:B::Pg=HASH(0x9e95fd4)',
    'attachments') called at Bugzilla/DB.pm line 488
    [Thu Sep 21 10:20:58 2006] checksetup.pl:
    Bugzilla:B::bz_add_table('Bugzilla:B::Pg=HASH(0x9e95fd4)',
    'attachments') called at Bugzilla/DB.pm line 335
    [Thu Sep 21 10:20:58 2006] checksetup.pl:
    Bugzilla:B::bz_setup_database('Bugzilla:B::Pg=HASH(0x9e95fd4)')
    called at Bugzilla/DB/Pg.pm line 220
    [Thu Sep 21 10:20:58 2006] checksetup.pl:
    Bugzilla:B::Pg::bz_setup_database('Bugzilla:B::Pg=HASH(0x9e95fd4)')
    called at ./checksetup.pl line 1601
    -- end --

    I have also tried what I believe to be the first PostgreSQL compatible
    BugZilla, 2.20, and recieve the same error. Trying to use BugZilla
    results in SQL errors about columns not existing.

    My guess is that the datastructure of PgZilla isn't what BugZilla
    expects. Does a mapping or fixup script exist? Any advice would be most
    welcome!

    Thanks,
    Alastair


  2. Re: PgZilla 2.15 Migration


    Richard Broersma Jr wrote:
    >
    > I am not familiar with pgZilla. But my guest would be that the checksetup.pl is trying to create
    > a new DB scheme on top of the existing DB scheme. This process fails because these relations
    > already exist. I don't know if this is true for your pgZilla, but if you were trying to connect
    > to and existing Bugzilla database you would not have to following the installation instructions
    > where you re-create the DB schema. Just edit your configuration files to point to the correct
    > server and database.



    Hi,

    What you suggest is exactly what I am trying to to. I have the 2.15
    install of PgZilla working on a new machine with a copy of the database
    from the existing live PgZilla. I installed alongside a 2.22 (and 2.20)
    BugZilla and used the existing localconfig file in the same way you
    would do a standard upgrade between regular Bugzilla versions.


  3. bugzilla customization and CVS best practices

    Hi,

    This certainly seems like a faq item, so please point me to the right resource if I missed it.

    We have customizations to bugzilla (changed the templates, CSS, etc).

    What's the best practice for keeping these customizations under source control? Keep the whole bugzilla-2-18 (or whatever) tree in a local CVS project, and check the changes out directly to the /usr/loca/bugzilla/ directory on our production box? (By 'local cvs project' I mean an independent copy of the mozilla bugzilla cvs project).

    Finally, I had a problem where permission one some of the files got whacked when I checked out from cvs. (I don't recall which one, but I believe it lost 'Are there any secrets to preserving permissions with cvs?).

    thanks,

    bill m


  4. Re: PgZilla 2.15 Migration

    On Thu, 2006-09-21 at 03:30 -0700, Al wrote:
    > I have inherited a RedHat PgZilla 2.15 installation that I would love
    > to migrate onto a current BugZilla.


    That won't be possible without a custom script. Perhaps ask Red Hat if
    they've written one.

    Otherwise, you could perhaps contract a consultant to write one, or
    write one yourself.

    -Max
    --
    http://www.everythingsolved.com/
    Everything Solved: Competent, Friendly Bugzilla and Linux Services


  5. Re: bugzilla customization and CVS best practices

    Bill Milbratz wrote:

    > We have customizations to bugzilla (changed the templates, CSS, etc).
    > What's the best practice for keeping these customizations under source control?


    Officially, you should be keeping your modifications in the "custom"
    directory, and checking those into your own source control.

    But I found keeping such parallel custom directories painful because I
    had to do a lot of manual merging each time I CVS update'd the main
    Bugzilla.

    So now what I do is that I have created my own local repository of the
    entire Bugzilla tree. I started with the standard Bugzilla 2.18 tree
    (back then), imported on a "vendor branch", and then merged that into
    the head, and applied our site customizations, and checked them in.

    Now, when new releases come out, I import those into the same "vendor
    branch", and do a merge of the changes between the last release and the
    current release into the head, and then deal with whatever breakages
    occur (very few, really).

    This way, we can perform fairly automatic updates to new releases as
    they come out. Though I've recently been stuck on the 2.20.x series,
    because our server is an FC3 server which doesn't have MySQL 4.x. (Sure,
    I could get it, but it's a pain to slide it past IT controls..)

  6. Re: PgZilla 2.15 Migration

    Max Kanat-Alexander wrote:
    > That won't be possible without a custom script. Perhaps ask Red Hat if
    > they've written one.
    >
    > Otherwise, you could perhaps contract a consultant to write one, or
    > write one yourself.
    >
    > -Max


    I figured as much, but I thought I'd ask I'd best get looking at the
    schema.

    Thanks,
    Alastair


+ Reply to Thread