Bugzilla:Moving From CVS To Bazaar: Difference between revisions

Jump to navigation Jump to search

Bugzilla:Moving From CVS To Bazaar (view source)

Revision as of 17:58, 2 March 2012

4,194 bytes removed ,  2 March 2012
no edit summary
No edit summary
No edit summary
Line 1: Line 1:
{{draft}}
{{draft}}


== Upgrading from CVS to Bzr ==
== Upgrading from CVS to bzr ==


If you are upgrading from a Bugzilla version 4.0 or older using CVS to Bugzilla 4.2 or newer this page is of particular interest to you as Bugzilla 4.2 now requires use of Bzr.
This page applies to people whose installation of Bugzilla is a checkout from CVS, and who wish to upgrade from 4.0 or earlier to Bugzilla 4.2 or newer. Bugzilla 4.2 and later are not available in our CVS repository, only our Bazaar (bzr) repository. Therefore, you will need to change your installation over to pull from bzr before upgrading to 4.2. If you use our tarballs to download and upgrade Bugzilla, then you don’t need to be concerned with this page.  


As announced 3 years ago in the developers mailing-list and on b.m.o., and 1.5 years ago on the bugzilla.org website, the Bugzilla team switched from the old CVS to the more modern Bazaar (or bzr for short) VCS. If you use our tarballs to download Bugzilla, then you don’t really care about this change, and the process to upgrade won’t change for you. If you use CVS and you wonder how to upgrade using Bzr, here is how you can do it:
XXX How can someone tell if their Bugzilla falls into this category?


=== Saving Local Customizations ===
The procedure is as follows:


For now, there is no need to shut down Bugzilla. We will do this when we start the upgrade process itself. If you made changes to the Bugzilla code itself (instead of using its extension system), you will have to port these changes to the new version, else they will be lost. If you made no changes, or all changes are contained into extensions, you can jump to step 2 directly. To generate a patch with all the changes you made, go into your bugzilla/ directory and run this command:
=== 1. Update Your Bugzilla To The Latest Point Release ===
 
Update your Bugzilla from CVS to the latest minor release of your branch, using CVS update.
 
XXX Expand
 
You should then use your Bugzilla for a day or two to make sure it's all still working fine.
 
=== 2. Save Any Local Customizations ===
 
If you have customizations to your Bugzilla, and you made them by changing the Bugzilla code itself (rather than using the Extension system), you will have to keep a copy of those changes. If you made no changes, or all changes are contained into extensions, jump to step 3.  
 
To generate a patch with all the changes you made, go into your bugzilla/ directory and run this command:


   cvs diff -puN > patch.diff
   cvs diff -puN > patch.diff
Line 15: Line 27:
The file patch.diff will contain all the changes you made to your current installation.  
The file patch.diff will contain all the changes you made to your current installation.  


=== Downloading Code from Bzr ===
XXX What about people who have done point releases by manually applying patches? Does anyone do that?


Let’s download the new version of Bugzilla into a separate directory, to not mess with the current installation. Now you will need bzr. All Linux installations have it; have a look at your package manager. For instance, Fedora 16 has bzr-2.4.2-1.fc16.i686.rpm. On Windows, you can download it from http://bazaar.canonical.com. The standalone application is recommended; for instance: bzr-2.4.2-1-setup.exe. Once bzr is installed, run this command to download Bugzilla 4.2:
=== 3. Download Code from bzr ===
 
Download a copy of your current version of Bugzilla from the bzr repository into a separate directory. You will need a copy of the bzr program. All Linux installations have it; have a look in your package manager. For instance, Fedora 16 has bzr-2.4.2-1.fc16.i686.rpm. On Windows, you can download it from http://bazaar.canonical.com; The standalone application is recommended, which has a name like bzr-2.4.2-1-setup.exe. Once bzr is installed, run this command to download Bugzilla :
    
    
   bzr co bzr://bzr.mozilla.org/bugzilla/4.2 bugzilla42
   bzr co bzr://bzr.mozilla.org/bugzilla/<version> bugzilla-bzr


Here, bzr co means “checkout”, i.e. it’s the first download of 4.2 with bzr. Then you have the URL to our Bugzilla 4.2 repository, and finally you have the name of the local directory into which to dowload the source code. If you don’t like the name bugzilla42, feel free to choose another one if you prefer.
Replace <version> with the version number of your current Bugzilla, e.g. 3.6. "bugzilla-bzr" is the name of the local directory into which the source code will be downloaded.


=== Checking for Required Modules ===
=== 4. Shut Down Bugzilla ===


Now go into the new bugzilla42/ directory and run the following command:
At this point, you should shut down Bugzilla to stop anyone changing the data you are about to copy. Go into the administrative interface and put an appropriate message into the "shutdownhtml" parameter.
   
  ./checksetup.pl –check-modules


The –check-modules part is important for two reasons. First of all, we didn’t copy the configuration files from the old bugzilla/ directory into the new one. The advantage to do so is to prevent Bugzilla 4.2 from finding where your DB is located and start interacting with it. Remember that we did no backup of your DB yet! And the second reason is that we first want to make sure that we have all the required Perl modules installed. Between major releases of Bugzilla, the requirements may change, either by requiring new Perl modules, or by requiring a newer version of an existing Perl module. If you have missing or too old Perl modules, you will have to install or upgrade them, ideally using your package manager. On Windows, ActivePerl 5.12 and newer have all the required modules available, so that’s not a problem. On Linux, only old distros may have some missing or too old Perl modules. If this happens, you can use the install-module.pl script which is in the same directory as checksetup.pl to install them. The commands you need to execute are given by checksetup.pl –check-modules itself. Note that you don’t need to install all the optional Perl modules. Only install those which are relevant to your installation.
=== 5. Copy Across Data and Modules ===


=== Applying Local Customizations ===
Copy the contents of the following directories from your current installation of Bugzilla into the corresponding directory in bugzilla-bzr/:


If you made changes to your current Bugzilla installation, then you have to apply patch.diff you created earlier to your new installation. If you made no changes, you can jump to the next step. If you are on Windows and you don’t have patch.exe, you can download it from http://gnuwin32.sourceforge.net/packages/patch.htm. Once downloaded, you must copy patch.exe into the Windows directory. At this point, it’s very likely that your changes will conflict with the new code, unless you are lucky or your changes are very minor. So we first check if there are conflicts or not. To do that, copy patch.diff into your new bugzilla42/ directory, and run this command from here:
  lib/
   
  data/
  patch -p0 –dry-run < patch.diff
  extensions/ (any extensions you have written or installed, not ones which ship with Bugzilla like BmpConvert, Example, OldBugMove or Voting)


–dry-run means that we made no changes to files; it was only a test. If all you get are messages such as “Hunk #1 succeeded at 79 (offset -26 lines)” or “Hunk #1 succeeded at 31 with fuzz 1 (offset 2 lines)”, then you are fine. But if you get messages such as “Hunk #1 FAILED at 27″ and “1 out of 2 hunks FAILED”, then you will need to make some manual changes. If the conflicts are minor, you can easily fix them manually, else you probably will have to rewrite your changes directly into the new code. If you have no conflicts, you can drop the –dry-run argument and apply your patch for real:
Copy the following files from your current installation of Bugzilla into the corresponding place in bugzilla-bzr/:


   patch -p0 < patch.diff
   localconfig
 
Because your two versions of Bugzilla are the same, this should all work fine.
 
=== 6. Reapply Local Customizations ===


=== Shutting Down Bugzilla ===
If you recorded any changes to your current Bugzilla installation in step 1, then you have to apply patch.diff you created earlier to your new installation. If you made no changes, you can jump to the next step. If you are on Windows and you don’t have patch.exe, you can download it from http://gnuwin32.sourceforge.net/packages/patch.htm. Once downloaded, you must copy patch.exe into the Windows directory. Copy patch.diff into the bugzilla-bzr directory and then:


Now we are ready to start the upgrade process itself. The first thing to do is to shut down Bugzilla, because the DB must not be accessed by anyone but you during the upgrade process. To do that, go to Administration > Parameters > General > shutdownhtml, and add some explanation of what’s happening. For instance: “This installation is being upgraded to Bugzilla 4.2. The downtime should last approximatively 2 hours.”, and click the “Save Changes” button at the bottom of the page. It is recommended that you don’t leave this page during the upgrade process, because all other pages will be deactivated besides this one. At this point, when someone tries to access Bugzilla during the downtime, this message will be displayed to them instead, so that you can upgrade your installation without having some users still interacting with it.
  patch -p0 < patch.diff


=== Backing Up the Database ===
The patch should apply cleanly because you have exactly the same version of Bugzilla in both directories.


Then, and this rule applies all the time when upgrading to a newer major version: do a backup of your database! The reason is that once you start the upgrade process (i.e. when you run checksetup.pl), there is NO way to downgrade later. So if the upgrade process fails for some reason (most of the time because someone hacked the source code or the DB schema) and you made no backup, there may be data loss. To backup your DB with MySQL, run the following command, where you must replace $db_user and $db_name by their value set in your bugzilla/localconfig file (by default: $db_user = bugs; $db_name = bugs):
=== 6. Swap The New Version In ===
   
  mysqldump -u $db_user -p $db_name > db_backup.sql


=== Moving Over Data Files ===
Rename your old Bugzilla directory to bugzilla-cvs, and rename your bugzilla-bzr directory to whatever name your Bugzilla directory had. Run checksetup.pl to confirm that all is well.


Copy the whole data/ directory and the localconfig file from your old bugzilla/ directory into the new bugzilla42/ one. data/ contains your parameters in the data/params file, your local attachments in data/attachments/ as well as data for Old Charts in data/mining/. And localconfig contains all the parameters to access the DB, including its password, the name of the web server group, and some other useful configuration information. If you wrote some extensions, now is a good time to also copy them into bugzilla42/extensions/. Only copy the ones you wrote, not the existing ones such as BmpConvert, Example, OldBugMove or Voting, which are maintained by the Bugzilla team.
  mv bugzilla bugzilla-cvs
  mv bugzilla-bzr bugzilla
  cd bugzilla
  ./checksetup.pl


=== Starting the Upgrade ===
=== 7. Re-enable Bugzilla ===


It’s now time to upgrade your DB to work with Bugzilla 4.2. From the bugzilla42/ directory, run ./checksetup.pl with no arguments (so no –check-modules anymore) and let it run the upgrade process for you. As you copied the configuration and parameters files, it knows where the DB is, its password, and everything else it should know about. Depending on the size of your DB and from which version you are upgrading, this may take from a few minutes to several hours. But typically, it’s of the order of a few tens of minutes for a DB with several tens of thousands of bugs. If everything went well, the last message displayed by checksetup.pl must be “checksetup.pl complete” displayed in green. Else this means something went wrong at some point. If half of the messages are in red, then there is no doubt about this.
Go into the administrative interface and clear the contents of the "shutdownhtml" parameter.


=== All Done ===
=== 8. Upgrade Bugzilla ===


The upgrade is now complete, and it’s time to let your users admire this new version. Replace your old bugzilla/ directory by the new one, and re-enable Bugzilla. To do that, you must remove the text you wrote for the shutdownhtml parameter. As we replaced the old directory by the new one, the URL pointing to Bugzilla remains unchanged. You now have a fully-working bzr-based Bugzilla installation.
Use your Bugzilla for several days to check that the switch has had no detrimental effects. Then, follow the normal instructions for upgrading a bzr install of Bugzilla to the latest version. XXXlink
Gerv
Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/403377"

Navigation menu