Reset du dépot git des cahiers à prévoir #7

Closed
opened 3 years ago by arpinux · 6 comments
arpinux commented 3 years ago
Owner

coucou les humains :)

je sais pas si vous avez remarqué, mais le poids du git/lescahiers augmente vite car il y a 80 Mo à chaque push avec les différentes vesion des cahiers dedans.

alors je prévois une reset du dépot juste après la refonte, cad la suppression complète des anciennes versions/commits/branches menant à ce poids dépassant maintenant les 500 Mo (un peu lourd pour les sources d'un manuel :P)

donc une fois la refonte terminée, je propose de supprimer purement et simplement le dépot "lescahiersdudebutant---buster", puis le recréer, mais avec un "first commit" ne prenant en compte que la nouvelle version toute belle :)

dans le même temps, je m'appliquerai à ne pas push avec les versions (PDF/EPUB/HTML/DEB) intégrées afin d'alléger la charge serveur pendant la refonte, et après bien sûr :)

allez ... hop ... j'y retourne :D

coucou les humains :) je sais pas si vous avez remarqué, mais le poids du git/lescahiers augmente vite car il y a 80 Mo à chaque push avec les différentes vesion des cahiers dedans. alors je prévois une reset du dépot juste après la refonte, cad la suppression complète des anciennes versions/commits/branches menant à ce poids dépassant maintenant les 500 Mo (un peu lourd pour les sources d'un manuel :P) donc une fois la refonte terminée, je propose de supprimer purement et simplement le dépot "lescahiersdudebutant---buster", puis le recréer, mais avec un "first commit" ne prenant en compte que la nouvelle version toute belle :) dans le même temps, je m'appliquerai à ne pas push avec les versions (PDF/EPUB/HTML/DEB) intégrées afin d'alléger la charge serveur pendant la refonte, et après bien sûr :) allez ... hop ... j'y retourne :D
Owner

Justement je me demandais, c'est pas totalement merdique d'inclure le "résultat" de compilation dans un git ? Faut y mettre que les sources d'après moi.

Justement je me demandais, c'est pas totalement merdique d'inclure le "résultat" de compilation dans un git ? Faut y mettre que les sources d'après moi.
Poster
Owner

il faut bien un endroit pour héberger les versions...

ou alors utiliser le "dossier" mentionné ici https://http.debian-facile.org/git/ProjetsDF/lescahiersdudebutant---buster/issues/2#issuecomment-163 pour héberger les versions stables PDF/EPUB/HTML/DEB et ainsi, préserver les dépôts git.

mais il me faudrait un accès du coup, que je puisse faire une jolie page d'accueil et des liens propres vers les version à choper. du coup, pour DFiso, pas besoin de se poser de questions, juste à choper le .deb stable avant de build une ISO.

en attendant, je stop les push des résultats de compilation, je ne push que les images et fichiers sources.

il faut bien un endroit pour héberger les versions... ou alors utiliser le "dossier" mentionné ici https://http.debian-facile.org/git/ProjetsDF/lescahiersdudebutant---buster/issues/2#issuecomment-163 pour héberger les versions stables PDF/EPUB/HTML/DEB et ainsi, préserver les dépôts git. mais il me faudrait un accès du coup, que je puisse faire une jolie page d'accueil et des liens propres vers les version à choper. du coup, pour DFiso, pas besoin de se poser de questions, juste à choper le .deb stable avant de build une ISO. en attendant, je stop les push des résultats de compilation, je ne push que les images et fichiers sources.
Owner

En alternative à un nouveau dépôt, avec une perte complète de l’historique, je me propose de réécrire l’historique de celui-ci au signal de @arpinux pour en retirer toute trace des pdf/epub/etc.

L’historique étant plutôt court, c’est une opération qui ne devrait pas me prendre beaucoup de temps.


Pour le stockage des versions stables je suis en faveur de ne pas utiliser le dépôt git pour ça, sinon ce souci finira par se reproduire.

Il y a pas mal de solutions pour éviter ça, je me propose d’en développer une basée sur les tags git : un serveur tiers qui aille quotidiennement contrôler ce dépôt git, et construise les pdf/epub/etc. correspondant aux tags avant de les mettre à disposition sur un serveur Web. Il suffirait donc d’utiliser des tags pour définir les versions à construire, qui se retrouveraient automatiquement disponibles au téléchargement (moyennant un certain délai).

En alternative à un nouveau dépôt, avec une perte complète de l’historique, je me propose de réécrire l’historique de celui-ci au signal de @arpinux pour en retirer toute trace des pdf/epub/etc. L’historique étant plutôt court, c’est une opération qui ne devrait pas me prendre beaucoup de temps. --- Pour le stockage des versions stables je suis en faveur de ne pas utiliser le dépôt git pour ça, sinon ce souci finira par se reproduire. Il y a pas mal de solutions pour éviter ça, je me propose d’en développer une basée sur les tags git : un serveur tiers qui aille quotidiennement contrôler ce dépôt git, et construise les pdf/epub/etc. correspondant aux tags avant de les mettre à disposition sur un serveur Web. Il suffirait donc d’utiliser des tags pour définir les versions à construire, qui se retrouveraient automatiquement disponibles au téléchargement (moyennant un certain délai).
Owner

Je suis d'accord avec vous trois, il ne faut pas avoir un dépôt obèse, mais pour ça, la solution c'est de ne pas se servir de git pour "publier" les fichiers compilés. Réécrire l'historique pour supprimer tout ça et changer de méthode de publication me semble être la meilleure option.

Je suis d'accord avec vous *trois*, il ne faut pas avoir un dépôt obèse, mais pour ça, la solution c'est de ne pas se servir de git pour "publier" les fichiers compilés. Réécrire l'historique pour supprimer tout ça et changer de méthode de publication me semble être la meilleure option.
Poster
Owner

cool si tout le monde est d'accord :)

je push encore un peu pour le gitignore à tester et je laisse @vv222 refaire l'historique...

cool si tout le monde est d'accord :) je push encore un peu pour le gitignore à tester et je laisse @vv222 refaire l'historique...
Poster
Owner

feu vert pour la purge de l'historique @vv222 :)

feu vert pour la purge de l'historique @vv222 :)
vv222 closed this issue 3 years ago
This repo is archived. You cannot comment on issues.
No Label
No Milestone
No Assignees
4 Participants
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.