Git permet de participer à de nombreux autres systèmes de contrôle de version, comme codice_1 ou codice_2.
SVN.
La compatibilité entre Git et est assurée par codice_1 qui autorise un utilisateur à accéder et participer à un dépôt SVN. Les utilisateurs peuvent générer des patchs locaux pour les envoyer par liste de diffusion, ou soumettre leurs changements aux dépôts d'origine.
Premiers pas.
Pour commencer à utiliser Git avec des projets sur des serveurs Subversion, il faut créer un dépôt local, et configurer codice_1 :
 mkdir projet1
 cd projet1
 git svn init <URL du dépôt root> -T/chemin/du/tronc
 git svn fetch -r <première révision>:HEAD
Le paramètre "première révision" peut être "1", mais pour gagner du temps il est possible de ne prendre que les 10 dernières révisions. codice_5 indique alors ces révisions.
Généralement quand on travaille avec des dépôts Subversion, on communique l'URL du projet complète. Pour déterminer l'URL du dépôt racine :
 git svn info <URL du dépôt root>
Une ligne du résultat indique le dépôt racine. Le chemin du tronc est simplement le reste de l'URL qui suit.
Il est possible de simplement donner à codice_1 l'URL complète du projet, mais cela peut stopper la possibilité de travailler sur des branches SVN.
Exemples.
Obtenir Pywikipedia :
$ git svn init http://svn.wikimedia.org/svnroot/pywikipedia/trunk/pywikipedia/
Initialized empty Git repository in .../.git/
$ git svn fetch -r 1:HEAD
r370 = 318fb412e5d1f1136a92d079f3607ac23bde2c34 (refs/remotes/git-svn)
 D treelang_all.py
 D treelang.py
W: -empty_dir: treelang.py
W: -empty_dir: treelang_all.py
r371 = e8477f292b077f023e4cebad843e0d36d3765db8 (refs/remotes/git-svn)
 D parsepopular.py
W: -empty_dir: parsepopular.py
r372 = 8803111b0411243af419868388fc8c7398e8ab9d (refs/remotes/git-svn)
 D getlang.py
W: -empty_dir: getlang.py
r373 = ad935dd0472db28379809f150fcf53678630076c (refs/remotes/git-svn)
 A splitwarning.py
Récupérer AWB (AutoWikiBrowser) :
$ git svn init svn://svn.code.sf.net/p/autowikibrowser/code/
Initialized empty Git repository in .../.git/
$ git svn fetch -r 1:HEAD
r15 = 086d4ff454a9ddfac92edb4013ec845f65e14ace (refs/remotes/git-svn)
 M AWB/AWB/Main.cs
 M AWB/WikiFunctions/WebControl.cs
r16 = 14f49de6b3c984bb8a87900e8be42a6576902a06 (refs/remotes/git-svn)
 M AWB/AWB/ExitQuestion.Designer.cs
 M AWB/WikiFunctions/GetLists.cs
 M AWB/WikiFunctions/Tools.cs
r17 = 8b58f6e5b21c91f0819bea9bc9a8110c2cab540d (refs/remotes/git-svn)
 M AWB/AWB/Main.Designer.cs
 M AWB/AWB/Main.cs
 M AWB/WikiFunctions/GetLists.cs
r18 = 51683925cedb8effb274fadd2417cc9b1f860e3c (refs/remotes/git-svn)
 M AWB/AWB/specialFilter.Designer.cs
 M AWB/AWB/specialFilter.cs
r19 = 712edb32a20d6d2ab4066acf056f14daa67a9d4b (refs/remotes/git-svn)
 M AWB/WikiFunctions/WPEditor.cs
r20 = 3116588b52a8e27e1dc72d25b1981d181d6ba203 (refs/remotes/git-svn)
Interagir avec le dépôt.
L'avantage de travailler avec Git sur des dépôts SVN est l'utilisation en local. Dans ce cas :
 git stash # cache les changements pour obtenir un arbre propre
 git svn fetch # amène les derniers changements
 git rebase trunk
 git stash apply
La première et la dernière ligne ne sont pas nécessaires si l'arbre est propre.
Le codice_11 laisse les soumissions locales au dessus du HEAD SVN.
Changements locaux.
Pour éviter de propager des modifications locales indésirables (débogages, tests...), avec codice_12, sans les perdre peut passer par deux approches.
Premièrement, maintenir une branche locale pour chacune qui devra contenir des changements locaux. Par exemple faire un codice_13 sur "branche1" au-dessus de "branche1-locale". Exemple :
 git rebase trunk branche1-locale
 git rebase branche1-locale branche1
Deux choix sont ensuite possibles, effectuer directement les changements sur la branche locale, ce qui est plus rapide que de les soumettre à la branche distante avant de les récupérer dans la locale. Ensuite il est possible d'utiliser codice_14 pour les retirer de la branche distante.
Comme une alternative à l'approche centrée recombinaison, il existe une méthode basée sur la fusion. Tout en conservant les changements sur une branche locale, mais sans avoir à conserver la branche au dessus de la branche locale par recombinaison.
C'est un avantage car :
Donc à la place des recombinaisons, on crée une nouvelle branche servant à la construction. Il faut la démarrer avec la soumission à tester. Ensuite codice_15 fusionne la branche locale, apportant tous les changements dans un seul arbre. La raison de cette fusion dans une branche reconstruction est pour dissuader l'utilisation de codice_8 (qui soumettrait les tests indésirables sur le serveur).
Cette approche peut même rendre facultative la recombinaison quotidienne la branche avec le tronc. En cas de branches multiples, les recombinaisons permanentes peuvent s'avérer chronophages :
git checkout build
git reset --hard trunk # s'assurer de l'absence de changement important
git merge branche1 branche1-locale
La construction contient ensuite les changements du tronc, branche1 et branche1-locale !
Il est possible de conserver plusieurs branches locales dont une avec les tests. Cette approche peut être développée avec une branche par sujet dans un arbre :
git merge sujet1 sujet2 config debug...
Malheureusement, la fusion de cette pieuvre ne résout pas les conflits. Dans ce cas il faut appliquer les fusions une par une :
git merge sujet1
git merge sujet1
git merge local
Envoyer des changements en amont.
Éventuellement, pour soumettre au serveur des branches sujet avec un accès codice_17, on peut lancer codice_8. Cela prendra chaque soumission locale dans la branche courante et le soumettra à subversion. Par exemple avec trois soumissions locales, après codice_19 il y aura trois nouvelles soumissions dans subversion.
Sans accès codice_17, le patch devra probablement être soumis via une liste de diffusion ou un logiciel de suivi de problèmes (). Pour cela on peut utiliser git-format-patch. Par exemple pour trois soumissions locales :
git format-patch HEAD~3..
Le résultat sera trois fichiers en $PWD, 0001-commit-name.patch, 0002-commit-name.patch, et 0003-commit-name.patch, qui pourront être attachés à des emails ou joint à Bugzilla. Remarque : il existe git-send-email pour envoyer les emails directement :
git send-email *.patch
Si les séries de patchs ne sont pas dans l'ordre, voir codice_21.

Technologie/Lignes et services de métros/Le matériel roulant du métro de Paris

Technologie/Lignes et services de métros/Le matériel roulant du métro de Paris/Le MP59

Le MP59 
Le MP59 (Matériel Pneu appel d’offres 59) est le plus vieux matériel roulant encore en service commercial à Paris.
Il circulait sur les lignes 1, 4 et 11. 
Il fut retiré de la ligne 1 à partir de 1997 et de la ligne 4 à partir de 2010 pour laisser sa place au MP89. Actuellement il circule uniquement sur la ligne 11. 
Le MP59 a roulé la première fois en 1963. Il remplaçait son prédécesseur le MP55 qui ne roule plus actuellement. 
Sur la ligne 4 le MP59 circulait avec cette composition de 6 voitures et de 90 m : Mc-M-R-R-M-Mc 
Sur la ligne 11 avec cette composition de 4 voitures et de 60m : Mc-M-R-Mc

Technologie/Lignes et services de métros/Le matériel roulant du métro de Paris/Le MF67

Le MF67 
Le MF67 (Matériel Fer appel d'offres 1967) est le matériel utilisé sur la plupart des lignes.
Avant 2007 il couvrait 7 lignes du métro parisien : 
À partir de 2007, le MF67 a commencé à se faire réformer de la ligne 2 puis de la 5 et maintenant de la 9 pour laisser sa place au MF01(ou MF2000).
Actuellement, il ne couvre plus que :
Les MF67 ont pu connaître des rénovations plus ou moins différentes selon la ligne. Tout d’abord tous les MF67 ont connu le retrait de leur banquettes. Ceux de la ligne 3 ont connu une rénovation plus approfondie : mise en service de ASVA (plan lumineux), changement de l'éclairage, ...

Photographie/Sociétés et Organisations/Éditeurs de cartes postales/M. Brossette