summaryrefslogtreecommitdiffstats
path: root/docs
diff options
context:
space:
mode:
authorFrédéric Buclin <LpSolit@gmail.com>2012-03-10 16:07:54 +0100
committerFrédéric Buclin <LpSolit@gmail.com>2012-03-10 16:07:54 +0100
commit248bb8b7272fdad0fc34dc193512d9085ec3f5b6 (patch)
tree4c8f6045e262132095e8594aad8edbb67c9530ec /docs
parenta9f0a3f34b1cc8a7d6c969c69b3b7c849fae22a1 (diff)
downloadbugzilla-248bb8b7272fdad0fc34dc193512d9085ec3f5b6.tar.gz
bugzilla-248bb8b7272fdad0fc34dc193512d9085ec3f5b6.tar.xz
Bug 730032: The documentation must mention bzr instead of cvs in the "Upgrading to New Releases" section
r=dkl a=LpSolit
Diffstat (limited to 'docs')
-rw-r--r--docs/en/xml/installation.xml134
1 files changed, 78 insertions, 56 deletions
diff --git a/docs/en/xml/installation.xml b/docs/en/xml/installation.xml
index d5217706f..bf9c5a1cc 100644
--- a/docs/en/xml/installation.xml
+++ b/docs/en/xml/installation.xml
@@ -2018,21 +2018,22 @@ chmod o+x . data data/webdot
<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
@@ -2128,10 +2129,10 @@ chmod o+x . data data/webdot
<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.
@@ -2156,12 +2157,12 @@ chmod o+x . data data/webdot
<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>
@@ -2181,8 +2182,8 @@ chmod o+x . data data/webdot
<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
@@ -2191,41 +2192,53 @@ chmod o+x . data data/webdot
</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>
@@ -2234,7 +2247,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.
@@ -2251,18 +2264,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>
@@ -2273,6 +2286,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
@@ -2288,15 +2310,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&mdash;that is, one where only the
- last number of the revision changes, such as from 2.22 to
- 2.22.1&mdash;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&mdash;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
@@ -2305,21 +2327,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 &lt; 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 &lt; 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>
@@ -2379,7 +2401,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.