Skip to content
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

Closed
fgallaire opened this issue Mar 21, 2017 · 8 comments
Closed

Multiple VCS backends #35

fgallaire opened this issue Mar 21, 2017 · 8 comments

Comments

@fgallaire
Copy link
Member

fgallaire commented Mar 21, 2017

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).

@Seb35
Copy link
Member

Seb35 commented Mar 22, 2017

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.

@fgallaire
Copy link
Member Author

J'avais switché en anglais sans m'en rendre compte..retour au français !

Pas de librairie multi-vcs pour trois raisons je pense :

  • Git est tellement dominant que le support des autres VCS n'intéresse pas beaucoup
  • les projets liés à d'autres VCS le sont en général pour une bonne raison/fonctionnalité spécifique
  • problème des licences

@hashar
Copy link

hashar commented Nov 20, 2017

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?

@fgallaire
Copy link
Member Author

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.

@fenollp
Copy link

fenollp commented Nov 21, 2017

Il y a-t-il un reel besoin de supporter d'autres VCS que Git ? Exemple ?
Je ne suis pas contre, mais les "it would be good" tuent des projets tous les jours.

BTW https://github.com/DanielDent/git-annex-remote-rclone peut surement en interesser quelques uns.

@fgallaire
Copy link
Member Author

fgallaire commented Nov 21, 2017

Ce n'est certainement pas un ajout éventuel non bloquant qui va tuer ce projet...
Par ailleurs supporter plusieurs VCS permet de survivre au déclin/disparition de l'un d'eux (même si ça semble peu probable pour Git, ça reste plus probable que la disparition des dinosaures), et de garantir globalement un meilleur code, i.e. découplé de la backend.

Et #47 est une raison qui se suffit à elle-même.

@Seb35
Copy link
Member

Seb35 commented Mar 3, 2018

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" Stockage (j’ai l’impression que ça n’est pas l’habitude dans le monde Python, mais ça m’aide à structurer et documenter le code). Cette structure a besoin d’une autre interface Organisations qui a elle-même besoin d’une interface Syntaxes. Cf #24 pour plus de détails sur ces interfaces annexes.

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 StockageGitFichiers). Dès que la nouvelle structuration fonctionnera, je m’attaquerai à #51 qui sera une variante de stockage dans Git, plus efficace et légèrement différente en ce sens qu’elle ne créera que des dépôts Git --bare.

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.

Seb35 added a commit that referenced this issue Mar 9, 2018
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.
@Seb35
Copy link
Member

Seb35 commented Mar 17, 2018

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.

@Seb35 Seb35 closed this as completed Mar 17, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants