Ce que je retiens de ton message, c'est que, en théorie, c'est possible, mais en pratique ça n'a jamais été fait.
Cela dit, lire ton message me fait me demander si utiliser une forge type redmine (qui ne versionne pas, nous sommes d'accord) qui expose une API (REST, me semble) pour gérer les tickets ne permettrait pas justement de servir d'intermédiaire entre divers projets utilisant chacun divers (D)VCS et bugtrackers... en gros, s'il ne serait pas possible d'utiliser des forges classiques comme des agrégats de forges, ça permettrait vraiment de bosser sans être connecté, tout en permettant de lier des tickets à des tickets d'autres projets. La, fossil serait vraiment une putain de bonne solution!
Parce que bon, qui n'a jamais cherché à intégrer la gestion des tickets à son git, sérieusement? Le wiki, ok, c'est overkill, quoique, ça permets de documenter, ce qu'on a tant de mal à faire... bon, ok, je suis peut-être le seul, mais à voir l'état global des docs de libs, j'en doute...
Bref, tout ça pour dire qu'on peut comparer Fossil et Git sur la partie gestion de sources.
Mais pas sur la partie intégration avec d'autres logiciels, avec un éco-système.
Je pense très sincèrement que fossil est un projet intéressant, très adapté à certains cas, tout comme git l'est à d'autres, et seules la flemme et la dépendance à un langage interprété m'ont fait rejeter mercurial qui semble de réputation plus adapté à la majorité des projets (la flemme étant l'argument principal, qui n'est pas contrebalancé par la réputée meilleure facilité d'usage).
[^] # Re: Fossil
Posté par freem . En réponse à la dépêche Sortie de Garradin 0.9 : recherche avancée, exportation ODS, etc.. Évalué à 2. Dernière modification le 07 novembre 2018 à 20:49.
Ce que je retiens de ton message, c'est que, en théorie, c'est possible, mais en pratique ça n'a jamais été fait.
Cela dit, lire ton message me fait me demander si utiliser une forge type redmine (qui ne versionne pas, nous sommes d'accord) qui expose une API (REST, me semble) pour gérer les tickets ne permettrait pas justement de servir d'intermédiaire entre divers projets utilisant chacun divers (D)VCS et bugtrackers... en gros, s'il ne serait pas possible d'utiliser des forges classiques comme des agrégats de forges, ça permettrait vraiment de bosser sans être connecté, tout en permettant de lier des tickets à des tickets d'autres projets. La, fossil serait vraiment une putain de bonne solution!
Parce que bon, qui n'a jamais cherché à intégrer la gestion des tickets à son git, sérieusement? Le wiki, ok, c'est overkill, quoique, ça permets de documenter, ce qu'on a tant de mal à faire... bon, ok, je suis peut-être le seul, mais à voir l'état global des docs de libs, j'en doute...
Mais pas sur la partie intégration avec d'autres logiciels, avec un éco-système.
Je pense très sincèrement que fossil est un projet intéressant, très adapté à certains cas, tout comme git l'est à d'autres, et seules la flemme et la dépendance à un langage interprété m'ont fait rejeter mercurial qui semble de réputation plus adapté à la majorité des projets (la flemme étant l'argument principal, qui n'est pas contrebalancé par la réputée meilleure facilité d'usage).