[spip-dev] Outil checkout

Dev
1

Hello,

Petit retour de l’utilisation de l’outil checkout pour installer en git la version de trunk de spip.
Tout fonctionne et j’obtiens bien cette fois le répertoire squelettes-dist contrairement à l’outil git_loader.

Juste un point bizarre :

  • si je suis dans le répertoire essai/
  • je fais checkout spip contrib
    j’obtiens bien un spip dans essai/contrib/ mais j’ai aussi un fichier .gitsvnextmodules dans le répertoire essai/, soit au dessus du répertoire contenant le spip.

Je peux le virer ? Que fait-il là ?

2

Hello,

Petit up de la question, si quelqu’un a une réponse ?

3

tu peux le virer, mais il sera recréé si tu fais un up ou un recheckout. C’est un fichier extrait du git du SPIP pour récuperer tous les plugins en externals

4

Ah ben nickel c’est clair.

5

oui mais en git, chaque plugin est un projet et il n’y a pas de lien entre le core et les plugins-dist (pas d’équivalent de la notion externals en SVN).
On se sert donc de ce fichier qui décrit les externals svn pour aller checkout chaque plugin au bon endroit en git

6

Bonjour

Il n'y a pas d'équivalent des svn:externals dans git. Pour palier à ce
comportement subgit (qui fait la traduction snv<>git) gère un fichier
de correspondance.
Coté git ce fichier n'a pas de signification en soit. Toutefois cela
permet de commiter depuis git des mises à jour pour applicables pour
les svn:external.

La notion de distribution SPIP est actuellement géré par
svn:externals. Dans le cas du script de Cédric, il s'appuie donc sur
l'information traduit en git , dans le cas de mon script on s'appuie
sur l'organisation SPIP pour retrouver cette notion.

Km

7

Hello,

Oui ok, merci les amis.
En fait, sur le git_loader tu utilises l’API Gitea pour récupérer la liste des plugins via l’organisation.
Et ça te renvoie un JSON et c’est pour ça que tu as besoin de JQ ?

8

Salut

En fait, sur le git_loader tu utilises l'API Gitea pour récupérer la liste des plugins via l'organisation.
Et ça te renvoie un JSON et c'est pour ça que tu as besoin de JQ ?

Tout à fait.

Km

9

Bonjour

Il n’y a pas d’équivalent des svn:externals dans git. Pour palier à ce
comportement subgit (qui fait la traduction snv<>git) gère un fichier
de correspondance.
Coté git ce fichier n’a pas de signification en soit. Toutefois cela
permet de commiter depuis git des mises à jour pour applicables pour
les svn:external.

Bonsoir et merci…

Intéressant… http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html Je ne connaissais pas [n’ayant jamais été confronté au besoin et n’ayant jamais lu l’entièreté du manuel --quoique, pas sûr que je m’en serait souvenu…] Je découvre au passage que Tortoise le gère [je travaille sous Linux et uniquement en console, mais c’est intéressant de savoir comment une interface graphique peut ajouter des options en extra sans devenir usine à gaz) https://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-externals.html ; https://jmfeurprier.com/2009/12/10/simple-introduction-to-svn-externals/
Du coup, je pensais plutôt que c’est un truc que sait faire Git mais pas Subversion, sauf que de l’autre côté la fonctionnalité s’appelle sous-module et non externe https://git-scm.com/docs/git-submodule Et c’est également connu de Tortoise https://tortoisegit.org/docs/tortoisegit/tgit-dug-submodules.html Il y a aussi une fonctionnalité de sous-arborescence [que je n’ai pas encore eu l’occasion de pratiquer] https://help.github.com/en/github/using-git/about-git-subtree-merges
Bien entendu, le mode de fonctionnement des deux systèmes influence la fonctionnalité http://alexking.org/blog/2012/03/05/git-submodules-vs-svn-externals ; https://blog.jonathanoliver.com/git-submodules-like-svnexternals/ ; https://delicious-insights.com/fr/articles/git-submodules/ ; https://delicious-insights.com/fr/articles/git-subtrees/

Du coup, je me suis demandé s’il n’est pas possible de simplement convertir l’un en l’autre… Une petite recherche sur la fabuleuse place qu’est le web m’a fait découvrir
-* une extension Ruby [cela ne répond pas directement à la question et doit dater d’avant l’introduction de la fonctionnalité] http://danielcestari.com/git-external/
-* une extension Python [similaire au précédent mais utilise du JSON aussi et est pensé dans une optique d’importation/migration comme nous] https://github.com/develersrl/git-externals
-* un script shell d’importation à plat [on est plus dans un esprit chargeur ici] avec une arborescence cachée [à la .git/submodules-- et des liens symboliques] https://github.com/andrep/git-svn-clone-externals
-* une autre solution d’importation en lecture [pareillement chargeur donc] https://www.yergler.net/2009/07/21/git-svn-and-svnexternals/
-* un article intéressant [qui ne donne pas de solution mais confirme l’approche et est en faveur d’une certaine forge] https://www.leewillis.co.uk/including-git-repo-svn-external/

10

Bonjour

Désolé, il n'y pas d'équivalent des svn:externals coté git. Cela est
dû au fonctionnement même de git. (Note : les explications qui vont
suivre auront de gros abus de langages, c'est juste pour fixer les
idées).
Git fonctionne uniquement par identifiant de commit (SHA1). Les
informations de branches ou tags sont des marqueurs associés à des
commits (donc des instantanés). Tandis que SVN travaille sur des
répertoires.

Par exemple avec svn:externals depuis le dépôt A on peut cibler la
branche trunk du dépôt B distant. Dès qu'un commit sera fait sur
B/trunk, une simple mise à jour (svn checkout) permettra d'obtenir les
derniers commits depuis A.

Ceci n'est pas possible avec git. On ne peut identifier qu'un commit
spécifique. Le dépôt A ciblera le commit associé à la branche master
du dépôt B. Si des mises à jour sont faites sur B, cela ne remontera
pas dans A automatiquement. Il faudra faire un nouveau commit dans A
indiquant la nouvelle référence du commit associé à la branche master.
Pour se faire une idée on peut regarder le fichier .git/ORIG_HEAD qui
permet à git de savoir à quel commit correspond la branche courante de
travail.
Dès qu'une mise à jour du dépôt est faite (git commit / fetch / pull /
rebase ....) git va mettre à jour un tableau de correspondance pour
identifier les pointeurs de branches aux bons commits.

Le seul cas qui pourrait être considéré comme équivalent ce serait
avec les tags. Par définition ils sont immuables, une fois défini il
ne dois pas bouger dans le temps. Toutefois subtilité contrairement à
git, dans svn un tag est une branche comme une autre. C'est uniquement
la convention d'usage qui protège l'évolution dans le temps du tag.
Dans git le tag est écrit dans les informations de commit

En pratique coté git en natif on a :
* submodule
* subtree

Ces solutions ont le même travers, travailler sur des commits
uniquement. Donc il est impossible d'avoir le même comportement qu'un
svn:externals sur des branches.

Comme tu as pu le constater toutes les autres solutions sont des
outils externes qui tentent de pallier ce comportement. Ils ne sont
pas interchangeables et intrinsèquement ils garderont cette limitation
liée aux pointeurs sur les commits.
On trouvera aussi d'autres outils comme :
* https://linuxfr.org/news/tsrc-un-gestionnaire-de-depots-git
* https://subgit.com/gitx
* ....

Pour conclure je dirais svn:externals répond à une problématique de
packaging, c'est à dire comment faire dépendre/interagir plusieurs
projets entre eux. Git ne cherche pas à résoudre ce genre de
problématiques. C'est pourquoi il vaut mieux se tourner vers des
solutions comme composer. Ils sont réfléchis pour traiter ces
questions.

Km

11

Salut,

avec l'outil checkout.php de Cedric, je ne sais pas faire une mise à jour d'un SPIP installé et de tous ses plugins-dist, je sais pas si c'est prévu ?

Mais j'ai trouvé un outil super pratique, qui fait un git pull sur toute une série de sous répertoire (un équivalent de svn up *, qui n'est pas possible directement avec Git).

https://github.com/aibeb/gitfox

Du coup, dans un SPIP installé avec checkout :

# git pull
# g pull plugins-dist/

et tout est à jour.

12

Moi j’ai un bash tout con qui regarde chaque répertoires plugins-dist et plugins et fait un pull.
Faudra surement mettre à disposition ce genre d’outils pour simplifier les migrations des utilisateurs de svn vers git.

13

Yo

je rebondis sur le sujet en éspérant ne pas être hors fil

si je souhaite récupérer un plugin je fais dans mon terminal en étant placé sur le dossier plugins

svn checkout svn://zone.spip.org/spip-zone/_plugins_/Nom_Plugin/

mais la j'ai un soucis avec https://contrib.spip.net/Tri-des-articles-par-rubrique qui est sous GIT

Quel est la ligne magique en terminal pour récupérer le plugin ?

merci

pas trouver sur

https://www.christopheducamp.com/2013/12/15/github-pour-nuls-partie-1/

https://doc.ubuntu-fr.org/git

14

Le plugin est hébergé sur github, comme le dit la doc, à cette adresse :
https://github.com/nd-/tri_par_rubrique

Github propose directement un bouton "Clone or download".

Donc, soit on télécharge le zip depuis Github (mais dans ce cas autant l'installer par SVP), soit on le "checkout" avec la commande clone et l'url https fournie par Github :

git clone https://github.com/nd-/tri_par_rubrique.git

NB : avec git, checkout n'a pas le même sens qu'avec svn. On utilise "git checkout" pour changer de branche localement, par exemple.

15

Merci bien ...

Yo

je rebondis sur le sujet en éspérant ne pas être hors fil

si je souhaite récupérer un plugin je fais dans mon terminal en étant placé sur le dossier plugins

svn checkout svn://zone.spip.org/spip-zone/_plugins_/Nom_Plugin/

mais la j'ai un soucis avec Tri des articles par rubrique - SPIP-Contrib qui est sous GIT

Quel est la ligne magique en terminal pour récupérer le plugin ?

Le plugin est hébergé sur github, comme le dit la doc, à cette adresse :
https://github.com/nd-/tri_par_rubrique

Github propose directement un bouton "Clone or download".

Donc, soit on télécharge le zip depuis Github (mais dans ce cas autant l'installer par SVP),

justement je souhaite pas passer par la , j'ai un script qui tourne avec svn up* qui d'ailleurs ne fonctionnera plus avec git

mais la c'est une autre question

soit on le "checkout" avec la commande clone et l'url https fournie par Github :

git clone https://github.com/nd-/tri_par_rubrique.git

Super merci bien c'est exactement ce que je chercher

NB : avec git, checkout n'a pas le même sens qu'avec svn. On utilise "git checkout" pour changer de branche localement, par exemple.

ah effectivement faudra faire gaffe

du coup va falloir que je regarde le script

16

Salut

avec l'outil checkout.php de Cedric, je ne sais pas faire une mise à
jour d'un SPIP installé et de tous ses plugins-dist, je sais pas si
c'est prévu ?

git loader est sensé répondre à besoin. Il fera un git pull des des
différents plugins et squelettes.

Mais j'ai trouvé un outil super pratique, qui fait un git pull sur toute
une série de sous répertoire (un équivalent de svn up *, qui n'est pas
possible directement avec Git).

GitHub - aibeb/gitfox: 🔥 execute git command on all subdirectories

A noté comme alternative intéressante.

Du coup, dans un SPIP installé avec checkout :

# git pull
# g pull plugins-dist/

N'oublies pas squelettes-dist

17

Je profite également de la discussion pour suggérer mise en place d'une petite doc/tutoriel/manuel/pense-bête sur cette question de migration svn=>git.
Je pense être un utilisateur "semi-avancé" de SPIP, et j'avoue que je suis un peu dans le flou actuellement pour savoir quelle est la conduite à tenir / quelles sont nouvelles habitudes à prendre pour passer de svn à git.
Entre les branches,les trunk, les master, les externals, les plugins qui sont encore sur svn mais pas sur github etc..., euh, j'avoue que ce n'est franchement pas clair dans ma petite tête et je suppose que je ne suis pas le seul à me poser des questions du style : "Euh, pour mon site, pour ma mutu, je fais comment : ça va marcher encore longtemps un svn up ? Et si je n'ai pas svn sur mon serveur, mais que git, il faut faire comment ? etc... etc..."
Qu'en pensez-vous de la mise en place d'un petit aide-mémoire quelque part ?
(Je veux bien donner un coup de main s'il y a besoin de rédiger quelque chose)

18

Excellente idée ,

d'ailleurs on a deux gros chapitre il me semble

- un site SPIP

- une MUTU

Avec dedans la partie

- SVN

- GIT

De plus faire un point sur les différents nom utilisé (comme tu le fais remarqué) : les branches,les trunk, les master, les externals,

ensuite effectivement je voie passé github, gitea, git, composer

et les différentes commandes

je me demande même si spip-cli ne devrais pas avoir son chapitre

bref je rame également

et je veux bien aussi participer dans la rédaction et interrogation

la j'en suis grace au réponse de la liste que

svn up* ne fonctionnera plus et qu'il faut utilisé git clone https://github.com/nd-/

mais du coup pour une maj c'est plugins par plugin alors qu'avant on travailler sur un ensemble

vous voyez bien " que je suis un peu dans le flou actuellement"

19

Salut,

il y a une doc en cours par là : https://blog.smellup.net/spip.php?article109

                 jean marie
20

Oui, j'avais vu passer ces articles. Il me semble toutefois qu'ils sont sur un positionnement un peu "pointu", plutôt destinés à ceux.elles qui, sans être forcément des pros, ont un peu d'aisance avec le terminal etc...

Il y a une catégorie d'utilisateurs - dans laquelle je m'inclus pour partie - qui ont des besoins un peu plus basiques limités à récupérer/mettre à jour à grands coups de svn co et svn up (plus rarement des svn revert) les plugins/squelettes... dont ils ont besoin

Les questions qu'ils se posent ressemblent quelque chose comme :

=> "bon, maintenant, il faut faire comment, ils sont où les plugins ?"

=> "Je supprime mes plugins et je les remplace via un git clone ?"

=> "Ah, tiens, sur git.spip.net c'est quoi la différence entre
cy.altern / spip_core : Dépôt officiel du core SPIP * Copie possible par svn sur svn://trac.rezo.net/spip * Les svn:externals sont présent dans https://git.spip.net/SPIP/[nom du plugin dist
et
SPIP / spip : Dépôt officiel du core SPIP * Copie possible par svn sur svn://trac.rezo.net/spip * Les svn:externals sont présent dans https://git.spip.net/SPIP/[nom du plugin dist]

=> "Tiens,pour formidable_tablesorter, par exemple, je trouve deux résultats :
plugin / formidable_tablesorter - Mis à jour il y a 1 mois
maieul / formidable_tablesorter - Mis à jour il y a 2 mois
lequel faut-il prendre ?"

=> "Tous les plugins sont là maintenant ou y a-t-il d'autres ressources git autre part ? Ça existe encore les externals, et si oui, on va les chercher comment "

=> "Et, pour les sites non mutualisés ou isolés, SVP ça va marcher encore ? Au fait, il va les chercher où ses plugins : sur le dépot git ?"

etc...

Bref, pas mal de questions (et il y en a sûrement plein d'autres) toutes simples, très concrètes dont les réponses pourraient constituer un aide-mémoire de premier niveau dont j'imagine qu'il pourrait rendre service à pas mal de gens.