Fossil a moins de fonctionnalités [...] mais propose [...]
Il a, en fait, plus de fonctionnalités, mais moins avancées. J'ai testé très rapidement a un moment, le fait d'avoir le wiki et le bugtracker intégrés me plaisaient bien.
Mais, voila, quand je l'ai testé, le bugtracker nécessitait pas mal de bidouillages pour avoir un truc correct, et je n'avais pas réussi a rendre l'interface en ligne de commande aussi agréable (pas trouvé a l'époque comment mettre la couleur, et je ne peux pas me passer de ça).
Autres inconvénients majeurs à mes yeux: celui qui veut utiliser un autre gestionnaire de projet (et non de code) se retrouve du coup avec du bloat (code inutile) en la présence justement du wiki et du bugtracker intégrés. Et pour finir, je ne connais pas de forge (service) proposant fossil, hors, ce dont on parle quand on parle de forge, c'est le plus souvent du service de forge, et non des logiciels derrière. Parce que perso, je n'ai strictement jamais aimé l'interface de github, que je trouve trop bordélique et lourde (je préférai SF.net quand c'était pas infesté, d'ailleurs SF à toujours des fonctionnalités que je ne vois pas chez les nouveaux acteurs), chez les nouveaux je préfère bitbucket. Pas encore testé gitlab.
push automatique après commit par exemple
Je ne comprend pas... tu veux dire qu'à chaque commit, tout est balancé sur le web sur un répo central? Ça casse un des arguments majeurs en faveur des DVCS, qui est de pouvoir coder dans le train (entres autres). Et ce comportement ne me semble pas favoriser l'usage de commit nombreux et atomiques (si je dois attendre que ma connection se synchronise avec un serveur, je vais avoir tendance à faire de gros commit regroupant plusieurs modifications, comme à l'époque de SVN).
Bref, j'aime bien l'idée de fossil, qui est d'être une forge (et non juste un DVCS) simple à déployer, mais en fait quand j'ai testé (il y à 3 ans, +/-) ce n'était pas encore ça. Le truc le plus utile du bouzin (je veux dire le gros avantage) nécessitait de bidouiller du SQL brut, et moi, le SQL c'est un truc que j'évite de toucher, j'aime pas, c'est comme ça (ça vous pète à la tronche au moindre relâchement j'ai l'impression).
Au fond, redmine est certes plus complexe à déployer, mais me semble plus utilisable out of the box. Pire, les devs n'ont que rarement un seul projet, alors le coût de déploiement du redmine se divise par le nombre de projets, tandis que celui de fossil se multiplie (configuration à refaire à chaque fois, notamment pour les ticquets).
Jamais testé les autres forges ou couples bugtracker+wiki.
[^] # Re: Fossil
Posté par freem . En réponse au journal Le danger github. Évalué à 4.
Il a, en fait, plus de fonctionnalités, mais moins avancées. J'ai testé très rapidement a un moment, le fait d'avoir le wiki et le bugtracker intégrés me plaisaient bien.
Mais, voila, quand je l'ai testé, le bugtracker nécessitait pas mal de bidouillages pour avoir un truc correct, et je n'avais pas réussi a rendre l'interface en ligne de commande aussi agréable (pas trouvé a l'époque comment mettre la couleur, et je ne peux pas me passer de ça).
Autres inconvénients majeurs à mes yeux: celui qui veut utiliser un autre gestionnaire de projet (et non de code) se retrouve du coup avec du bloat (code inutile) en la présence justement du wiki et du bugtracker intégrés. Et pour finir, je ne connais pas de forge (service) proposant fossil, hors, ce dont on parle quand on parle de forge, c'est le plus souvent du service de forge, et non des logiciels derrière. Parce que perso, je n'ai strictement jamais aimé l'interface de github, que je trouve trop bordélique et lourde (je préférai SF.net quand c'était pas infesté, d'ailleurs SF à toujours des fonctionnalités que je ne vois pas chez les nouveaux acteurs), chez les nouveaux je préfère bitbucket. Pas encore testé gitlab.
Je ne comprend pas... tu veux dire qu'à chaque commit, tout est balancé sur le web sur un répo central? Ça casse un des arguments majeurs en faveur des DVCS, qui est de pouvoir coder dans le train (entres autres). Et ce comportement ne me semble pas favoriser l'usage de commit nombreux et atomiques (si je dois attendre que ma connection se synchronise avec un serveur, je vais avoir tendance à faire de gros commit regroupant plusieurs modifications, comme à l'époque de SVN).
Bref, j'aime bien l'idée de fossil, qui est d'être une forge (et non juste un DVCS) simple à déployer, mais en fait quand j'ai testé (il y à 3 ans, +/-) ce n'était pas encore ça. Le truc le plus utile du bouzin (je veux dire le gros avantage) nécessitait de bidouiller du SQL brut, et moi, le SQL c'est un truc que j'évite de toucher, j'aime pas, c'est comme ça (ça vous pète à la tronche au moindre relâchement j'ai l'impression).
Au fond, redmine est certes plus complexe à déployer, mais me semble plus utilisable out of the box. Pire, les devs n'ont que rarement un seul projet, alors le coût de déploiement du redmine se divise par le nombre de projets, tandis que celui de fossil se multiplie (configuration à refaire à chaque fois, notamment pour les ticquets).
Jamais testé les autres forges ou couples bugtracker+wiki.