git-svn(1)

scandale, y a pas les #crayons

Oui c’est un scandale, le contributeur principal ne respecte pas les règles de commit :
–* ▻http://zone.spip.org/trac/spip-zone/browser/_plugins_/crayons
Il faut à minima un #trunk pour avoir du #git

c’est embêtant ça signifie péter tous les svn up ; cette règle est-elle absolue ? s’il faut vraiment en passer par là je crois que ça vaut le coup, mais j’aimerais comprendre pourquoi, pourquoi, pourquoi on se met tout le temps des bâtons dans les roues

On peut supposer que c’est lié à l’utilisation de l’outil de migration #git-svn qui peut faire des choses très sympa en récupération de l’historique avec l’une des options ’’’—stdlayout’’’ ou ’’’-T’’’ mais bon, ça peut être aussi autre chose, je fais que supposer... c’est souvent long à procéder, et le résultat n’est pas toujours à la hauteur, surtout quand les dev n’ont pas utilisé svn « comme il faut » pour gérer tags et branches ...

ô toi qui aime l’anglais, lis donc ça : ▻https://www.kernel.org/pub/software/scm/git/docs/git-svn.html

Yop

@fil tout #VCS recommande à minima la logique trunk/branches/tags, certains plugins suivent cette recommandation, d’autres non.
Il est parfois bon d’être rationnel et si possible de suivre les bonnes pratiques.
Autre point où copierons nous la branches créée depuis git dans la version svn ?

@james #git-svn n’est pas utilisé car ne fait pas le boulot voulu. Le « layout » utilisé permet d’être bijectif :
on peut contribuer indifféremment sur la copie git ou svn c’est pareil.

Question piège : à quoi ressemblerait le « layout » pour les plugins core ? :)

Est ce qu’on doit vraiment en passer par là, je dirais oui car il nous faut être cohérent pour ne pas se mettre des traverses dans les pieds, on a assez de bâtons pour le moment.

Je regarde pour que ce soit le plus transparent possible même pour ces plugins, mais ce n’est pas trivial.