3.11.3. Migrer à partir de CVS

La procédure pour migrer vers Git se fait comme suit. L’idée est de changer de système de contrôle de version sans changer la version de Bugzilla que vous utilisez, pour minimiser les risques de conflits ou de problèmes. Le changement de version peut donc se faire dans une étape séparée.

3.11.3.1. Télécharger le code avec Git

Tout d’abord, vous devez trouver la version de Bugzilla que vous utilisez. Elle devrait se trouver dans le coin supérieur droit de la page d’accueil. Si ce n’est pas le cas, ouvrez le fichier Bugzilla/Constants.pm dans votre répertoire Bugzilla et recherchez BUGZILLA_VERSION.

Ensuite, vous devrez télécharger une copie supplémentaire de votre version actuelle de Bugzilla à partir du dépôt Git, et la placer dans un répertoire séparé à côté de votre installation Bugzilla existante (nous supposerons qu’elle se trouve dans un répertoire appelé bugzilla).

Pour faire cela, vous aurez besoin d’une copie du programme git. Toutes les distributions Linux en ont une. Recherchez dans votre gestionnaire de paquets git. Sous Windows ou Mac OS X, vous pouvez télécharger le binaire officiel.

Une fois Git installé, exécutez ces commandes pour récupérer une copie de Bugzilla :

git clone https://git.mozilla.org/bugzilla/bugzilla bugzilla-new

cd bugzilla-new

git checkout release-$VERSION

Remplacez $VERSION avec le nombre à trois chiffres de la version de votre installation actuelle de Bugzilla, par ex. 4.2.2. (Si le dernier chiffre est un 0, omettez-le – utilisez donc 4.4 pour la première version de la série 4.4).

Vous verrez un message indiquant “detached HEAD”. Ne vous inquiétez pas, votre tête est toujours solidement attachée à vos épaules.

3.11.3.2. Sauvegarder les personnalisations locales

Rendez-vous dans votre répertoire actuel de Bugzilla et exécutez la commande suivante :

cvs diff -puN > patch.diff

Si vous avez réalisé des personnalisations dans votre installation Bugzilla et que vous l’avez fait en modifiant directement le code de Bugzilla (au lieu d’utiliser le système d’extension), alors le fichier patch.diff contiendra beaucoup de contenu. Conserver une copie de ce fichier et des modifications référencées par les lignes Only in. Si le fichier est vide ou s’il ne contient que du contenu insignifiant, vous n’avez pas fait de personnalisations de ce genre.

3.11.3.3. Arrêter Bugzilla

Maintenant, vosu devez arrêter Bugzilla pour être sûr qu’aucun changement ne survienne pendant la bascule. Rendez-vous dans l’interface d’administration et saisissez un message approprié dans le paramètre shutdownhtml, qui se trouve dans la section Général des paramètres d’administration. Comme son nom l’indique, le code HTML y est autorisé.

C’est le bon moment pour faire des Sauvegardes. Nous ne devrions pas toucher à la base de données, mais on ne saurait être trop prudent.

3.11.3.4. Copier les données et les modules

Copiez le contenu des répertoires suivants à partir de votre installation de Bugzilla actuelle vers le répertoire correspondant dans bugzilla-new/:

lib/
data/
template/en/custom (ce répertoire peut ne pas exister)

Vous devrez aussi copier toutes les extensions que vous avez écrites ou installées, qui se trouvent dans le répertoire extensions/. La commande cvs status extensions/ devrait vous permettre de voir ce que vous avez ajouté le cas échéant.

Enfin, copiez le fichier suivant à partir de votre installation actuelle de Bugzilla dans l’emplacement correspondant dans bugzilla-new/:

localconfig

Ce fichier contient le mot de passe et les détails de l’accès à la base de données. Vos deux versions de Bugzilla étant identiques, cela devrait fonctionner sans problème.

3.11.3.5. Réappliquer les personnalisations locales

Si votre fichier patch.diff est vide, vous pouvez passer à létape suivante. dans le cas contraire, vous devez appliquer le correctif dans votre nouvelle installation. Si vous êtes sous Windows et que vous n’avez pas le programme patch, vous pouvez le télécharger sur GNUWin. Une fois téléchargé, vous devez copier l’exécutable patch.exe dans le répertoire Windows.

Copiez patch.diff dans le répertoire bugzilla-new puis exécutez la commande suivante :

patch -p0 --dry-run < patch.diff

Le correctif devrait s’appliquer correctement car vous avez exactement la même version de Bugzilla dans les deux répertoire. Si c’est le cas, retirer l’argument --dry-run de la ligne de commande et relancez la commande pour appliquer les modifications. Si ce n’est pas le cas, c’est que vous avez des versions de Bugzilla différentes dans les deux répertoires.

3.11.3.6. Basculer vers la nouvelle version

Maintenant, intervertissez les répertoires et exécutez checksetup.pl pour confirmer que tout va bien. À partir du répertoire contenant les répertoires bugzilla et bugzilla-new, exécutez les commandes suivantes :

mv bugzilla bugzilla-old

mv bugzilla-new bugzilla

cd bugzilla

./checksetup.pl

L’exécution de checksetup.pl ne devrait pas modifier votre base de données. Si c’est le cas, c’est que vous avez deux versions de Bugzilla différentes.

3.11.3.7. Réactiver Bugzilla

Rendez-vous dans l’interface d’administration et supprimez le contenu du paramètre shutdownhtml.

3.11.3.8. Tester Bugzilla

Utilisez Bugzilla pendant plusieurs jours pour vérifier que la bascule n’a pas eu d’effet de bord. Ensuite, si nécessaire, suivez les instructions dans Mettre à jour avec Git pour mettre à jour vers la dernière version de Bugzilla.

3.11.3.9. Revenir en arrière

Si quelque chose s’est mal passé pendant le processus (par ex. votre correctif ne s’est pas appliqué ou checksetup.pl renvoie des erreurs), vous pouvez toujours réintervertir les répertoires (si vous êtes arrivé jusque là) et réactiver Bugzilla (si vous l’aviez désactivé) et recherchez de l’aide. Même si vous avez réactivé Bugzilla, et que vous rencontrez des problèmes peu de temps après, vous utilisez toujours la même version, donc il ne devrait pas y avoir pour revenir en arrière deux à trois jours après.

Cette documentation contient très probablement des bogues ; si vous en découvrez, veuillez les signaler ici.