diff options
Diffstat (limited to 'docs/en/xml')
| -rw-r--r-- | docs/en/xml/installation.xml | 134 |
1 files changed, 78 insertions, 56 deletions
diff --git a/docs/en/xml/installation.xml b/docs/en/xml/installation.xml index cfd9f14f3..e9830e29c 100644 --- a/docs/en/xml/installation.xml +++ b/docs/en/xml/installation.xml @@ -2021,21 +2021,22 @@ pid-file=/home/foo/mymysql/the.pid <section id="upgrade"> <title>Upgrading to New Releases</title> - + <para>Upgrading to new Bugzilla releases is very simple. There is - a script included with Bugzilla that will automatically - do all of the database migration for you.</para> - + a script named <filename>checksetup.pl</filename> included with + Bugzilla that will automatically do all of the database migration + for you.</para> + <para>The following sections explain how to upgrade from one version of Bugzilla to another. Whether you are upgrading - from one bug-fix version to another (such as 3.0.1 to 3.0.2) - or from one major version to another (such as from 3.0 to 3.2), + from one bug-fix version to another (such as 4.2 to 4.2.1) + or from one major version to another (such as from 4.0 to 4.2), the instructions are always the same.</para> <note> <para> Any examples in the following sections are written as though the - user were updating to version 2.22.1, but the procedures are the + user were updating to version 4.2.1, but the procedures are the same no matter what version you're updating to. Also, in the examples, the user's Bugzilla installation is found at <filename>/var/www/html/bugzilla</filename>. If that is not the @@ -2131,10 +2132,10 @@ pid-file=/home/foo/mymysql/the.pid <variablelist> <varlistentry> - <term>CVS (<xref linkend="upgrade-cvs"/>)</term> + <term>Bzr (<xref linkend="upgrade-bzr"/>)</term> <listitem> <para> - If have <command>cvs</command> installed on your machine + If you have <command>bzr</command> installed on your machine and you have Internet access, this is the easiest way to upgrade, particularly if you have made modifications to the code or templates of Bugzilla. @@ -2159,12 +2160,12 @@ pid-file=/home/foo/mymysql/the.pid <para> If you have made modifications to your Bugzilla, and you don't have Internet access or you don't want to use - cvs, then this is the best way to upgrade. + bzr, then this is the best way to upgrade. </para> - + <para> - You can only do minor upgrades (such as 3.0 to 3.0.1 or - 3.0.1 to 3.0.2) with patches. + You can only do minor upgrades (such as 4.2 to 4.2.1 or + 4.2.1 to 4.2.2) with patches. </para> </listitem> </varlistentry> @@ -2184,8 +2185,8 @@ pid-file=/home/foo/mymysql/the.pid <para> The larger the jump you are trying to make, the more difficult it is going to be to upgrade if you have made local customizations. - Upgrading from 3.0 to 3.0.1 should be fairly painless even if - you are heavily customized, but going from 2.18 to 3.0 is going + Upgrading from 4.2 to 4.2.1 should be fairly painless even if + you are heavily customized, but going from 2.18 to 4.2 is going to mean a fair bit of work re-writing your local changes to use the new files, logic, templates, etc. If you have done no local changes at all, however, then upgrading should be approximately @@ -2194,41 +2195,53 @@ pid-file=/home/foo/mymysql/the.pid </para> </section> - <section id="upgrade-cvs"> - <title>Upgrading using CVS</title> + <section id="upgrade-bzr"> + <title>Upgrading using Bzr</title> <para> - This requires that you have cvs installed (most Unix machines do), - and requires that you are able to access cvs-mirror.mozilla.org - on port 2401, which may not be an option if you are behind a - highly restrictive firewall or don't have Internet access. + This requires that you have bzr installed (most Unix machines do), + and requires that you are able to access + <ulink url="http://bzr.mozilla.org/bugzilla/">bzr.mozilla.org</ulink>, + which may not be an option if you don't have Internet access. </para> <para> The following shows the sequence of commands needed to update a - Bugzilla installation via CVS, and a typical series of results. + Bugzilla installation via Bzr, and a typical series of results. + These commands assume that you already have Bugzilla installed + using Bzr. </para> + <warning> + <para> + If your installation is still using CVS, you must first convert + it to Bzr. A very detailed step by step documentation can be + found on <ulink url="https://wiki.mozilla.org/Bugzilla:Moving_From_CVS_To_Bazaar">wiki.mozilla.org</ulink>. + </para> + </warning> + <programlisting> bash$ <command>cd /var/www/html/bugzilla</command> -bash$ <command>cvs login</command> -Logging in to :pserver:anonymous@cvs-mirror.mozilla.org:2401/cvsroot -CVS password: <emphasis>('anonymous', or just leave it blank)</emphasis> -bash$ <command>cvs -q update -r BUGZILLA-2_22_1 -dP</command> -P checksetup.pl -P collectstats.pl -P docs/rel_notes.txt -P template/en/default/list/quips.html.tmpl -<emphasis>(etc.)</emphasis> +bash$ <command>bzr switch 4.2</command> (only run this command when not yet running 4.2) +bash$ <command>bzr up -r tag:bugzilla-4.2.1</command> ++N extensions/MoreBugUrl/ ++N extensions/MoreBugUrl/Config.pm ++N extensions/MoreBugUrl/Extension.pm +... + M Bugzilla/Attachment.pm + M Bugzilla/Attachment/PatchReader.pm + M Bugzilla/Bug.pm +... +All changes applied successfully. </programlisting> <caution> <para> - If a line in the output from <command>cvs update</command> begins - with a <computeroutput>C</computeroutput>, then that represents a - file with local changes that CVS was unable to properly merge. You - need to resolve these conflicts manually before Bugzilla (or at - least the portion using that file) will be usable. + If a line in the output from <command>bzr up</command> mentions + a conflict, then that represents a file with local changes that + Bzr was unable to properly merge. You need to resolve these + conflicts manually before Bugzilla (or at least the portion using + that file) will be usable. </para> </caution> </section> @@ -2237,7 +2250,7 @@ P template/en/default/list/quips.html.tmpl <title>Upgrading using the tarball</title> <para> - If you are unable (or unwilling) to use CVS, another option that's + If you are unable (or unwilling) to use Bzr, another option that's always available is to obtain the latest tarball from the <ulink url="http://www.bugzilla.org/download/">Download Page</ulink> and create a new Bugzilla installation from that. @@ -2254,18 +2267,18 @@ P template/en/default/list/quips.html.tmpl <programlisting> bash$ <command>cd /var/www/html</command> -bash$ <command>wget http://ftp.mozilla.org/pub/mozilla.org/webtools/bugzilla-2.22.1.tar.gz</command> +bash$ <command>wget http://ftp.mozilla.org/pub/mozilla.org/webtools/bugzilla-4.2.1.tar.gz</command> <emphasis>(Output omitted)</emphasis> -bash$ <command>tar xzvf bugzilla-2.22.1.tar.gz</command> -bugzilla-2.22.1/ -bugzilla-2.22.1/.cvsignore +bash$ <command>tar xzvf bugzilla-4.2.1.tar.gz</command> +bugzilla-4.2.1/ +bugzilla-4.2.1/colchange.cgi <emphasis>(Output truncated)</emphasis> -bash$ <command>cd bugzilla-2.22.1</command> +bash$ <command>cd bugzilla-4.2.1</command> bash$ <command>cp ../bugzilla/localconfig* .</command> bash$ <command>cp -r ../bugzilla/data .</command> bash$ <command>cd ..</command> bash$ <command>mv bugzilla bugzilla.old</command> -bash$ <command>mv bugzilla-2.22.1 bugzilla</command> +bash$ <command>mv bugzilla-4.2.1 bugzilla</command> </programlisting> <warning> @@ -2276,6 +2289,15 @@ bash$ <command>mv bugzilla-2.22.1 bugzilla</command> </para> </warning> + <caution> + <para> + If you have some extensions installed, you will have to copy them + to the new bugzilla directory too. Extensions are located in + <filename>bugzilla/extensions/</filename>. Only copy those you + installed, not those managed by the Bugzilla team. + </para> + </caution> + <para> This upgrade method will give you a clean install of Bugzilla. That's fine if you don't have any local customizations that you @@ -2291,15 +2313,15 @@ bash$ <command>mv bugzilla-2.22.1 bugzilla</command> A patch is a collection of all the bug fixes that have been made since the last bug-fix release. </para> - + <para> If you are doing a bug-fix upgrade—that is, one where only the - last number of the revision changes, such as from 2.22 to - 2.22.1—then you have the option of obtaining and applying a + last number of the revision changes, such as from 4.2 to + 4.2.1—then you have the option of obtaining and applying a patch file from the <ulink url="http://www.bugzilla.org/download/">Download Page</ulink>. </para> - + <para> As above, this example starts with obtaining the file via the command line. If you have already downloaded it, you can omit the @@ -2308,21 +2330,21 @@ bash$ <command>mv bugzilla-2.22.1 bugzilla</command> <programlisting> bash$ <command>cd /var/www/html/bugzilla</command> -bash$ <command>wget http://ftp.mozilla.org/pub/mozilla.org/webtools/bugzilla-2.22-to-2.22.1.diff.gz</command> +bash$ <command>wget http://ftp.mozilla.org/pub/mozilla.org/webtools/bugzilla-4.2-to-4.2.1.diff.gz</command> <emphasis>(Output omitted)</emphasis> -bash$ <command>gunzip bugzilla-2.22-to-2.22.1.diff.gz</command> -bash$ <command>patch -p1 < bugzilla-2.22-to-2.22.1.diff</command> -patching file checksetup.pl -patching file collectstats.pl +bash$ <command>gunzip bugzilla-4.2-to-4.2.1.diff.gz</command> +bash$ <command>patch -p1 < bugzilla-4.2-to-4.2.1.diff</command> +patching file Bugzilla/Constants.pm +patching file enter_bug.cgi <emphasis>(etc.)</emphasis> </programlisting> <warning> <para> Be aware that upgrading from a patch file does not change the - entries in your <filename class="directory">CVS</filename> directory. - This could make it more difficult to upgrade using CVS - (<xref linkend="upgrade-cvs"/>) in the future. + entries in your <filename class="directory">.bzr</filename> directory. + This could make it more difficult to upgrade using Bzr + (<xref linkend="upgrade-bzr"/>) in the future. </para> </warning> @@ -2382,7 +2404,7 @@ bash$ <command>./checksetup.pl</command> <caution> <para> - If this is a major upgrade (say, 2.22 to 3.0 or similar), + If this is a major upgrade (say, 3.6 to 4.2 or similar), running <command>checksetup.pl</command> on a large installation (75,000 or more bugs) can take a long time, possibly several hours. |