Re: Composer, Packagist, gitea, gitlab et github sont dans un bateau

Salut

> Ça fait beaucoup. Tu comptes l'intégralité de la zone ?

Oui plugins, squelettes, contrib, .... J'avais fait une extration à la
louche et j'étais tombé sur un valeur de cette grandeur.


> >> Ils y sont ajoutés à la main par camille ou tcharlss je crois, selon les
> >> besoins.
> >
> > C'est documenté sur https://git.spip.net/contrib/importToGitea
> > La zone manquant de structure cohérente, la traduction se fait sur la
> > base de modèle. Cela permet d'indiquer comment un répertoire dans le
> > svn sera traduit. (présence de master, tags, branches). C'est ainsi
> > qu'on peut traiter des cas simple comme  "trunk", ou bien "trunk/,
> > branches/, tags/" et enfin les cas complexes des plugins-dists
> > Je crois qu'on couvre les différents cas type et qu'on peut traiter la
> > zone dans sa grande majorité.
>
> Ok je comprends, c'est ce qu'on retrouve donc dans saisies avec les
> branches git master, v1 et v2 en fonction des répertoires svn.

oui les plugins de la galaxie qui sont des sous sous répertoires.

> > Pou le moment je préfères que ce soit traité encore à la main pour :
> > * être sur qu'on couvre bien tous les cas
> > * gérer les ressources du serveur (pour le moment il est sous dimensionné)
>
> Si on décide de passer sur Gitea, il faudra qu'il le soit (c'est un peu
> lent parfois, en ce moment).
> Est ce que Gitea peut gérer autant de projets ? il y a des retours là
> dessus ?

A priori oui. Le serveur est lent pour 2 raisons principales :
* le sous dimensionnement du serveur (qui sera résolu quand j'aurais
réussi à tout migrer dans le nouveau DC (cf sujet trac et cie)
* la synchronisation git/svn , subgit est assez gourmand en ressources
plus que gitea lui même.

Un serveur plus costaud réglerait ces 2 problèmes. C'est dans ma liste d'action.

> De ce que j'en comprends, on pourrait au moins automatiser un import de
> _plugins_ non ?

Oui il me semble que les modeles couvre les cas. Il s'agirait d'un
boucle svn ls couplé à un controle de la présence du dépot git en
amont (pour ne pas écraser l'existant)

> Pour les autres, il faut en discuter oui, et est ce qu'il faut tout
> importer ?
> grenier, acotes, contribs, doc, graphismes, qui ne bougent plus du tout,
> on peut en laisser certains sur svn

C'est de l'organisationnel. On importer les projets à la demande.

> Par contre, ce paragraphe m'interpelle :
>
> > Subgit permet de gérer la synchronisation dans les 2 sens. Toutefois il faut prendre en compte qu’il est préférable de considérer un seul dépot de référence, le second étant un miroir. Pour les personnes ayant demandé la mise en place de cette fonctionnalité, il est fortement conseillé d’indiquer dans les informations du projet si celui ci priviligie git ou svn. Le chapitre suivant peut être pris comme base et amélioré.
>
> Ça me parait assez casse gueule de gérer au cas par cas.
> Est ce qu'on ne pourrait pas décider qu'à un moment, c'est le dépôt git
> qui fait référence *dans tous les cas*, à partir du moment ou il existe ?
> Ce serait une règle beaucoup plus simple et claire pour tout le monde.

Oui et non, car c'est plus une approche d'usage que technique.
"Mince quel dépôt est le bon ? svn ou git ?"
Les 2 mon capitaine
"Tu es sur ?"
Oui mais bon si tu veux te rassurer sache que les principales
contributions se font depuis git|svn comme indiqué dans lisez.moi
"Ah ok, alors je vais faire comme c'est indiqué"

La configuration actuelle de subgit :
* considère que la forge de référence est svn, c'est à dire que si
lors d'un conversion il y a doute (incohérence de date de commit,
....) mais que cela peut être corrigé automatiquement c'est sur la
base de svn que cela sera fait.
*  si la synchronisation ne peut être faite pour diverses raisons,
subgit va remonter un message d'erreur indiquant les contrôles a
effectuer et comment corriger.

Pour le moment je n'ai pas encore eu de retour obligeant de régénérer
un depot git.
On pourrait changer la configuration par défaut et dire que git est le
réferentiel en cas de doute, toutefois c'est une configuration globale
car le faire au cas par cas serait très compliqué à gérer
individuellement. En terme de maintenance ça serait aussi compliqué à
suivre.
Donc on peut changer mais de façon globale.
Pour être honnête tant qu'il resterait un bout de svn à part, je ne
vois pas trop l’intérêt d'un tel changement.

km
_______________________________________________
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip