-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multiple VCS backends #35
Comments
Agreed! Bonus question: is there a good multi-vcs Pythonic library? Else probably something which should be abstracted inside Archéo Lex or even better as a standalone library. |
J'avais switché en anglais sans m'en rendre compte..retour au français ! Pas de librairie multi-vcs pour trois raisons je pense :
|
Je serai tenter de rejeter cette demande. Si quelqu'un a vraiment besoin de Mercurial ou Bazaar, il devrait pouvoir convertir le dépôt sans trop de difficulté. Autant ne pas compliquer les choses? |
Git et Mercurial sont équivalents, mais pas Bazaar ni Darcs, on perdrait des informations en convertissant de Git. Ce sont des backends, quelques lignes dans un fichier indépendant du reste, ça ne complique pas grand chose. |
Il y a-t-il un reel besoin de supporter d'autres VCS que Git ? Exemple ? BTW https://github.com/DanielDent/git-annex-remote-rclone peut surement en interesser quelques uns. |
Ce n'est certainement pas un ajout éventuel non bloquant qui va tuer ce projet... Et #47 est une raison qui se suffit à elle-même. |
Dans la restructuration en cours du code, j’abstrais (entre autres) l’écriture du/des fichiers résultat. La restructuration en cours sont les fichiers FabriqueArticle.py, FabriqueSection.py et le dossier exports où j’ai fait une "interface" Actuellement, il n’y a qu’un seul stockage, à savoir le stockage en dépôt Git et plus particulièrement en écrivant un vrai fichier puis en prenant en compte ce fichier Git (classe Quand la restructuration sera active par défaut, je fermerai cette issue comme résolue puisqu’il sera possible d’avoir plusieurs backends VCS ; si quelqu’un a besoin d’un VCS spécifique (Mercurial, Bazaar, Pijul, etc), il faudra ouvrir une issue spécifique. |
Le format de sortie est géré par différentes abstractions permettant de générer différents formats de sortie tout en dissociant bien le code interne : * syntaxe utilisée : Markdown, etc. * organisation des fichiers : un fichier unique, un article par fichier (sans répertoires), etc. * versionnement : Git, etc. (#35) Pour chaque abstraction, une "interface" est proposée. Étant donné l’ampleur du changement, il est possible que ces interfaces évoluent dans les semaines qui viennent. Au passage, un cache de sections (#32) est implémenté pour éviter de recalculer (récursivement) les sous-sections. La difficulté est de repérer (récursivement) la plus proche date interne de fin de vigueur, ce qui est fait en retournant ce résultat avec le texte de la section pour invalider toutes les sections parentes au-delà de cette date de fin de vigueur. Le gain de temps de calcul est environ 30 à 100 (pifométriquement, ça passe d’heures de calcul à minutes de calcul). Avec le travail sur le cache de sections a été vérifié de façon plus fine différentes exceptions sur les dates de vigueur. Entre autres, l’exception où la date de début de vigueur est 2999-01-01 (=absence de date) notamment utilisée dans les arrêtés. Cela pourrait corriger #11 et #30.
La restructuration et abstraction de cette partie étant active depuis une semaine, cette issue est résolue. Comme dit dans le commentaire précédent, si vous voulez un backend spécifique, ouvrez une issue spécifique. Personnellement, je ne suis pas intéressé par d’autres backends que Git et Pijul (à moyen terme), si vous proposez un backend autre que ces deux-là, venez avec une Pull Request, je ne ferai pas l’implémentation moi-même. |
Git is not the only one VCS. Mercurial and Bazaar are great too. It could be good to have a multi-backends architecture + Git support, so anyone could add other VCS (mercurial and bazaar are Python libs, so this could be done quite easily).
The text was updated successfully, but these errors were encountered: