[gull] Pb Mediawiki: bravo Git

Laurent Franceschetti laurent at franceschetti.net
Tue Oct 14 16:00:05 CEST 2008


Bonjour,
 
Le 22 mai dernier j'avais envoyé, une question concernant la méthode à
suivre pour vivre avec une version "maison" de mediawiki, qui évolue
parallèlement à la version officielle.
 
Après m'être un peu renseigné, j'ai tenté le coup avec Git
(http://git.or.cz/) qui est l'outil utilisé par le kernel Linux. Il est très
fort justement pour le développement distribué et la gestion des branches.

En fait ça marche et même plutôt à l'aise: ma version patché est synchro
avec mediawiki 1.13.2! J'ai reconstruit mon dépôt grosso modo de la façon
suivante:

A)Création du répertoire
	1) Repris la version 1.12 et mise dans un répertoire mediawiki.
	2) git init ; git add . ; git commit -m "Version 1.12" # ça me crée
le dépôt master

B) Création d'une branche
	3) créé une branche, par ex. MaVersion.
	4) fait un checkout sur MaVersion (pour le moment identique à la
1.12)
	5) supprimé toute l'arborescence, sauf le dossier .git
	6) recopié ma version à moi.
	7) fait les git add de rigueur + git commit; j'ai maintenant ma
branche, qui est dérivée de master.

C) Mise à jour de la dernière version officielle
	8) nouveau checkout sur master
	9) supprimé toute l'arborescence, sauf le dossier .git
	10)reprise la dernière version et mise dans mon répertoire mediawiki
	11) fait les git add de rigueur + git commit; j'ai maintenant ma
branche "master à jour".

D) Merge avec ma branche
	11) checkout sur la branche MaVersion
	12) git pull . master # ici le miracle: j'"aspire" la version de
master dans la branche MaVersion
	13) tenté le commit; il me signale une demi-douzaine fichiers en
conflit (champion Midas!)
	14) j'édite les fichiers du répertoire. Aux lignes indiquées, je
trouve les diff, je choisis mes versions.
	15) tester
	16) commit

Voilà; il y a peut-être mieux comme méthode, mais ça a le mérite de marcher!

Si j'ai bien compris [corrigez-moi!], la raison pour laquelle git est si
fort, est la suivante: contrairement à Subversion, git ne garde pas
l'historique linéraire du développement, mais il garde un *arbre*. Cela veut
dire que chaque fois qu'on tente un merge il peut remonter tout l'historique
jusqu'à l'ancêtre commun. Donc quand il fait un merge, il reconstruit
intelligemment le tout en repartant depuis ce point zéro (et non depuis la
dernière version).

Autre chose que j'apprécie
1) le répertoire de travail EST le dépôt. Quand je travaille seul, je trouve
superflu et générateur de questions administratives, de forcément devoir
constituer un dépôt à part (pourquoi faire?).
2) Un seul sous répertoire .git; ça ne pollue pas l'arborescence avec tout
un tas dossiers .svn. 
3) Si on est plusieurs par exemple développement open source, on constitue
un répertoire qui la référence, et les autres font un git clone.  Ensuite
git fetch pour la synchro vers le local -- on se retrouve avec TOUT le
projet en local. [ev. git push pour la synchro vers le dépôt principal, je
n'ai jamais essayé]. Simple, logique et ça permet de travailler offline
	

Bonne journée.
Laurent
________________________________
Bonjour,

J'ai installé mediawiki 1.12 pour en faire un site perso. Comme chacun sait,
il est configuré d'usine pour faire du wiki à large échelle (donc tout
ouvert) et pas pour les besoins d'une toute petite équipe sur l'Internet.
Bref, si elle met ça en ligne, elle n'a pas le poids pour lutter contre le
vandalisme et ça risque de finir en carnage.

En plus mediawiki requiert de la bidouille. Comme un grand, j'ai donc
retroussé mes manches et entrepris de modifier le php à gauche et à droite
pour qu'il convienne à ce cahier des charges (pas très difficile car les
recettes sont bien documentées, mais ça prend du temps et c'est un peu
lassant). En plus, j'ai pris la précaution de me doter de subversion
(Tortoise en fait) et donc j'ai un historique.

Maintenant j'aimerais faire 2 choses:
1) Au moment où je veux faire une "livraison", j'aimerais générer un patch,
histoire de faciliter le portage sur une machine avec la 1.12 déjà
installée, voire de partager mon humble travail.
2) Quand il y aura une nouvelle version du logiciel, comment devrai-je faire
pour fusionner mes modifs avec cette nouvelle version?

Quelqu'un pourrait m'orienter? Notez que ma connaissance de Subversion est
basique et qu'elle se limite à la lecture du livre de Mike Mason et à
l'utilisation pour 1 ou 2 personnes.

Merci et A+
Laurent






More information about the gull mailing list