Voir ce qui a été modifié entre plusieurs versions d'un article

Si ça marche, c'est juste super !

Douterais-tu de mes compétences ? ;D

Je sens qu'avec les améliorations qui arrivent, je vais passer plus souvent sur cette page !

Moi aussi !

Edit : P'tite question ! Je ne sais pas, si ça rentre dans la cadre de cette PR, mais bon.. Oh pire, au-moins vous serez au courant ! Est-il possible d'étaler l'historique sur plusieurs pages ? Car quand il y a un long historique, la page met énormément de temps à se charger !

Si on étale l'historique sur plusieurs pages, il ne sera pas possible de comparer deux commits qui sont sur deux pages différentes (à par si on le fait à la main).

Si on étale l'historique sur plusieurs pages, il ne sera pas possible de comparer deux commits qui sont sur deux pages différentes (à par si on le fait à la main).

Arf oui.. ! Je n'avais pas pensé à cela !

Merci Situphen pour ta PR, je viens de mergé et de commité pour avoir de jolies dates, du genre : "il y a 12 heures" ou "vendredi 1 janvier 2014 à 12h".

Est-il possible d'étaler l'historique sur plusieurs pages ? Car quand il y a un long historique, la page met énormément de temps à se charger !

Il serait envisageable par exemple d'afficher par défaut que les 20 derniers commits (ceux qu'on utilise le plus sont les plus récents…) et de proposer un lien pour tous les afficher (genre qui rajoute un ?all dans l'URL) et recharge la page mais avec la liste complète.

EDIT: Actuellement le JS est nécessaire pour comparer deux versions qcq. Pour résoudre cela on pourrait virer la dernière colonne du tableau avec les liens "Activer". La personne aurait alors à cliquer sur la version puis dans la sidebar "Mettre à jour la bêta avec cette version"… Qu'en pensez-vous ?

EDIT2:

c'est pas drole, la zep12 est sensée bientôt arriver…

La ZEP apportera le nouveau outil diff pour les articles

EDIT: Actuellement le JS est nécessaire pour comparer deux versions qcq. Pour résoudre cela on pourrait virer la dernière colonne du tableau avec les liens "Activer". La personne aurait alors à cliquer sur la version puis dans la sidebar "Mettre à jour la bêta avec cette version"… Qu'en pensez-vous ?

Ça complique la mise en beta d'une version alors que tout le monde à le JS d'activé ! Donc je préfère la solution actuelle à base de JS

Si on étale l'historique sur plusieurs pages, il ne sera pas possible de comparer deux commits qui sont sur deux pages différentes (à par si on le fait à la main).

On pourrait charger l'historique dynamiquement au fur et à mesure (à la Google Images). Sachant qu'en pratique on compare souvent seulement avec la version antérieure, inutile de tout afficher.

Sinon, pourquoi y a-t-il deux colonnes de boutons radio ?

La ZEP apportera le nouveau outil diff pour les articles

c'est surtout que ça veut dire que :

• soit c'est la ZEP qui arrive en premier et vous devez revoir votre code
• soit c'est votre PR qui arrive en premier et on ralentit encore l'arrivée de la ZEP pour merger les codes.

Pour pouvoir comparer n'importe quelle version avec n'importe quelle autre, comme sur Wikipédia.

@artragis : je me trompe peut-être, mais j'ai souvenir que vous aviez expliqué qu'il ne fallait pas bloquer le dev de fonctionnalités intéressantes à cause de la ZEP-12, parce que sinon, y'a pas grand chose qui allait avancer…

Ah d'accord. En fait, les boutons d'une même colonne appartiennent au même groupe de boutons.

Par contre, pourquoi y a-t-il des cases sans bouton et d'autres avec un bouton grisé ? La colonne de gauche représente la version la plus ancienne, c'est ça ?

C'est ça. Il y a des boutons grisés, car tu ne peux comparer une version avec elle-même ou une version antérieure. Les deux cases vides, c'est parce que tu ne pourras jamais mettre la dernière version comme premier élément de la comparaison, ni la première version comme second élément.

@artragis et les autres: je pense que c'est "leur PR" qui va gagner, du coup faudra qu'on en tienne compte. Plus qu'à leur faire les yeux doux pour qu'il viennent la refaire chez nous

*fait des petits yeux suppliants*

Je peux éventuellement proposer une PR pour la ZEP-12. Par contre il faudrait la faire où/quand ?

sur mon dépôt, sur la branche "zep_12_double_stack". Le nouveau module s'appelle "tutorialv2" et réunit tutoriels et articles.

Je suis pas très doué mais quand je clique sur fork (après avoir cliqué sur ton lien) github me redirige vers yapper-git/zds-site forké depuis zestedesavoir. J'ai l'impression qu'il refuse d'avoir 2 dépôts avec le même nom (ce qui parait logique), mais je n'ai pas encore trouvé l'option pour choisir le nom :s

en fait tu n'as pas besoin de "reforker". Il suffit qu'en ligne de commande tu fasses : git remote add artragis https://github.com/artragis/zds-site pour que tu puisses accéder à mon dépôt grâce à git fetch artragis puis tu crées ta branche de travail avec git checkout -b ta-branche-de-travail artragis/zep_12_double_stack. Tu fais ton code, tu commit, tu fais un push avec git push origin ta-branche-de-travail et ensuite tu peux faire une PR vers mon github comme tu le ferais vers le code de zds, il te proposera un menu déroulant au moment de faire la PR.

Merci artragis, j'ai réussi à récupérer ta branche.

Je fais les modifications que pour tutorialv2 ou aussi pour tutorial ? Certaines modifications sont communes, genre dans zds/utils. Je les refais ou cela sera fait par le merge ? (mais alors comment tester le code actuel ?) N'y aurait-il pas de problème lors du merge ? (je suis pas un pro de git…)

Je fais les modifications que pour tutorialv2 ou aussi pour tutorial ?

que pour tutorialv2

? Certaines modifications sont communes, genre dans zds/utils.

tu peux donc tenter un "merge" propre, si ça marche pas, faudra qu'on regarde un jour ou l'autre en discutant sur le irc.

Voilà j'ai fait une PR pour la ZEP-12.

\o/ communauté de malades !