Franchement, j'ai testé les deux: git et fossil, et j'ai pas aimé fossil, y compris pour les petits projets.
Pourquoi?
Parce que le UN exécutable, on s'en tamponne royalement avec les distro linux: apt-get et basta. Sous windows, "git" fonctionne maintenant correctement (je mets des " parce que ça semble être un fork… enfin j'ai pas trop cherché à connaitre le statut exact) et avec tortoiseGIT il est bien mieux intégré.
Le coup du "git c'est plus complexe", là encore, je ne suis pas d'accord.
L'usage de base à la même complexité que fossil, et la documentation de git est plus accessible. Faire un commit, revenir à une version précédente, ajouter ou supprimer des fichiers est simplissime, peu importe lequel.
Niveau confort d'utilisation, git permets d'activer la couleur, même si ce n'est pas dans la configuration par défaut. Ca n'a l'air de rien, mais pour moi qui travaille principalement avec une console, la couleur n'est pas un gadget kikoolol, mais bien une fonctionnalité qui me permets de voir bien plus rapidement l'information que je cherche.
Pour ce qui est du suivi des tickets, je n'ai pas creusé le problème de redmine, mais j'imagine que rien n'empêche de versionner également sa bdd de tickets.
Mais de toute façon, comme je l'ai dit, j'utilise principalement la console, et, là encore, fossil pêche, si ce n'est pas la fonctionnalité, c'est par la doc: impossible de trouver comment modifier un ticket depuis la console!
Obligé de passer par son interface web, que (moi )j'ai trouvée foireuse et inutilement complexe. Mais ça, les goûts et les couleurs…
Bon, à la décharge de fossil, je ne suis pas un grand expert des bugtrackers, et j'installe rarement(jamais en fait) des bugtracker en local sur ma machine. Quand je trouve un bug, généralement j'annote dans le code, un petit ///fixme: blah et je garde une trace du bug. Le bug tracker me semble bien plus utile pour un non développeur…
Pour finir, avec le versionning de la doc: en général, j'utilise simplement un dossier "doc" dans mon code source, pour ce qui est réservé à l'utilisateur. Pour ce qui est destiné aux dev, bah, c'est dans le code, tout simplement, donc versionné aussi.
Bon, j'ai bien bashé fossil, mais il faut l'admettre: j'adore l'idée derrière. Je trouve juste que ça manque de possibilités en ligne de commande en fait:
couleur (manque extrêmement cruel pour moi)
pas de gestion des tickets (qui aurait rendu l'outil réellement un outil en ligne de commande, et non un outil bâtard obligeant à utiliser à la fois la CLI et la GUI)
et l'interface web qui pourrait difficilement être pire, mais ça, ça doit être lié à mes goûts. Je ne parle bien sûr pas du côté esthétique dont je me contrefout (et est customisable à souhait, plutôt aisément d'ailleurs), mais bien du fait que je trouve ce truc très compliqué à configurer: il faut quand même à chaque fois ou presque modifier des commandes SQL, qui m'ont semblé plutôt cryptiques. Je n'ai pas eu la même sensation avec les divers bugtrackers utilisés par sourceforge, savannah, github ou bitbucket.
Alors, oui, fossil à ses avantages, mais par pitié, il faut cesser de dire que fossil est plus simple et accessible que les autres, surtout pour de petits projets (qui n'ont pas forcément besoin de tout l'arsenal de git). Ou alors faut donner des exemples, qu'on puisse juger.
En l'état, fossil est une excellente idée, qui manque cruellement de facilité d'utilisation sur le point qui fait de lui une bonne idée: l'intégration des tickets. En plus de ça, il manque aussi de confort en ligne de commande sur les fonctionnalités standards… (j'aime la couleur quand je fais un diff, j'y peut rien, j'ai toujours aimé noël et ses sapins…)
PS: je me suis battu plus de 3H d'affilée avec fossil pour utiliser son supposé avantage, j'ai fini par lâcher l'affaire, histoire de coder un peu, voulu faire quelques commit, afficher des diff etc… et j'ai compris qu'en fait, git, c'est pas mal.
[^] # Re: le git et le couvert
Posté par freem . En réponse au journal Chiselapp ferme ses portes. Évalué à 2.
Franchement, j'ai testé les deux: git et fossil, et j'ai pas aimé fossil, y compris pour les petits projets.
Pourquoi?
Parce que le UN exécutable, on s'en tamponne royalement avec les distro linux: apt-get et basta. Sous windows, "git" fonctionne maintenant correctement (je mets des " parce que ça semble être un fork… enfin j'ai pas trop cherché à connaitre le statut exact) et avec tortoiseGIT il est bien mieux intégré.
Le coup du "git c'est plus complexe", là encore, je ne suis pas d'accord.
L'usage de base à la même complexité que fossil, et la documentation de git est plus accessible. Faire un commit, revenir à une version précédente, ajouter ou supprimer des fichiers est simplissime, peu importe lequel.
Niveau confort d'utilisation, git permets d'activer la couleur, même si ce n'est pas dans la configuration par défaut. Ca n'a l'air de rien, mais pour moi qui travaille principalement avec une console, la couleur n'est pas un gadget kikoolol, mais bien une fonctionnalité qui me permets de voir bien plus rapidement l'information que je cherche.
Pour ce qui est du suivi des tickets, je n'ai pas creusé le problème de redmine, mais j'imagine que rien n'empêche de versionner également sa bdd de tickets.
Mais de toute façon, comme je l'ai dit, j'utilise principalement la console, et, là encore, fossil pêche, si ce n'est pas la fonctionnalité, c'est par la doc: impossible de trouver comment modifier un ticket depuis la console!
Obligé de passer par son interface web, que (moi )j'ai trouvée foireuse et inutilement complexe. Mais ça, les goûts et les couleurs…
Bon, à la décharge de fossil, je ne suis pas un grand expert des bugtrackers, et j'installe rarement(jamais en fait) des bugtracker en local sur ma machine. Quand je trouve un bug, généralement j'annote dans le code, un petit ///fixme: blah et je garde une trace du bug. Le bug tracker me semble bien plus utile pour un non développeur…
Pour finir, avec le versionning de la doc: en général, j'utilise simplement un dossier "doc" dans mon code source, pour ce qui est réservé à l'utilisateur. Pour ce qui est destiné aux dev, bah, c'est dans le code, tout simplement, donc versionné aussi.
Bon, j'ai bien bashé fossil, mais il faut l'admettre: j'adore l'idée derrière. Je trouve juste que ça manque de possibilités en ligne de commande en fait:
Alors, oui, fossil à ses avantages, mais par pitié, il faut cesser de dire que fossil est plus simple et accessible que les autres, surtout pour de petits projets (qui n'ont pas forcément besoin de tout l'arsenal de git). Ou alors faut donner des exemples, qu'on puisse juger.
En l'état, fossil est une excellente idée, qui manque cruellement de facilité d'utilisation sur le point qui fait de lui une bonne idée: l'intégration des tickets. En plus de ça, il manque aussi de confort en ligne de commande sur les fonctionnalités standards… (j'aime la couleur quand je fais un diff, j'y peut rien, j'ai toujours aimé noël et ses sapins…)
PS: je me suis battu plus de 3H d'affilée avec fossil pour utiliser son supposé avantage, j'ai fini par lâcher l'affaire, histoire de coder un peu, voulu faire quelques commit, afficher des diff etc… et j'ai compris qu'en fait, git, c'est pas mal.