Ce que je reproche à git, notamment pour un usage de ce type:
ne résiste pas aux déconnections (git clone d'un truc un peu gros sur une connection pourrie, couper la co: doit reprendre à zero);
performances exécrables (overhead du disque dur, bande passante, surtout quand on commence a utiliser des submodules), d'ou l'existence de git-lfs d'ailleurs (jamais testé, je sais pas ce que ça vaut, mais ça sent le workaround a 10 km);
interface horrible (on va pas se mentir: utiliser git, ça va à peu près, quand on a l'habitude, mais il suffit de voir quelqu'un qui apprend... c'est pas simple du tout). Attention: je ne connais pas mieux (ce qui ne veut pas dire que ça n'existe pas) mais le problème reste réel;
Outre ces points, il requiert une série d'actions complexes pour synchroniser des points ensemble, et je ne parle que de point à point (la gestion des conflits est loin d'être simple, et les patchs de conflit à résoudre qu'il génère sont loin d'être minimaux ou d'avoir une sémantique potable, en tout cas par défaut, peut-être que ça se configure...). Je n'ose imaginer le merdier à gérer pour avoir plus de 2 ou 3 cibles "remote"... et ça, c'est probable que ça soit pour tous les DVCS.
Il est possible qu'un autre DVCS fasse mieux: got par exemple, l'implémentation WiP d'openBSD, ou, possiblement encore plus mieux (parce que liés à git d'aucune façon), fossil, mercurial... mais git est bien le dernier que j'utiliserais pour un tel usage (je part du principe que le réseau ne doit pas être élitiste, donc un truc facile à utiliser et à apprendre pour un non-dev).
Probablement fossil, en fait. Au moins, par défaut il a une interface graphique (je considère une application web comme une interface graphique, oui), et déplacer un dépôt fossil est nettement plus simple: un seul fichier à déplacer.
[^] # Re: git?
Posté par freem . En réponse au journal Un réseau offline "delay-tolerant" avec NNCP. Évalué à 4.
Alors, git... non.
Un DVCS, oui, peut-être, mais pas git.
Ce que je reproche à git, notamment pour un usage de ce type:
Outre ces points, il requiert une série d'actions complexes pour synchroniser des points ensemble, et je ne parle que de point à point (la gestion des conflits est loin d'être simple, et les patchs de conflit à résoudre qu'il génère sont loin d'être minimaux ou d'avoir une sémantique potable, en tout cas par défaut, peut-être que ça se configure...). Je n'ose imaginer le merdier à gérer pour avoir plus de 2 ou 3 cibles "remote"... et ça, c'est probable que ça soit pour tous les DVCS.
Il est possible qu'un autre DVCS fasse mieux: got par exemple, l'implémentation WiP d'openBSD, ou, possiblement encore plus mieux (parce que liés à git d'aucune façon), fossil, mercurial... mais git est bien le dernier que j'utiliserais pour un tel usage (je part du principe que le réseau ne doit pas être élitiste, donc un truc facile à utiliser et à apprendre pour un non-dev).
Probablement fossil, en fait. Au moins, par défaut il a une interface graphique (je considère une application web comme une interface graphique, oui), et déplacer un dépôt fossil est nettement plus simple: un seul fichier à déplacer.