Fossil, une forge pour DVCS

Posté par  (site web personnel) . Édité par NeoX, baud123, tuiu pol, Nÿco et patrick_g. Modéré par NeoX.
Étiquettes :
51
17
fév.
2012
Gestion de versions

Fossil est le système de fichiers de Plan9. Ce n'est pas le sujet de cete dépêche.

Fossil c'est aussi un outil de gestion de version décentralisé, DCVS en court. Il est toujours un peu osé, par les temps qui courent, de parler d'un autre DCVS que le très apprécié Git, mais Fossil c'est aussi un peu plus que ça ; un plus qui m'a beaucoup séduit.

Fossil c'est aussi un wiki, un outil de gestion de tickets et une interface Web (et son serveur) dans un seul exécutable. Sans entrer dans les détails, il prend en charge les mêmes fonctionnalités que la plus grande partie des DCVS. Il se veut robuste et fiable, simple, un protocole réseau simple (HTTP) rendu suffisamment efficace pour fonctionner sur une ligne téléphonique 56k et facile d'utilisation (pas de configuration, commande simple). Ça c'est la partie "marketing".

Si la description sonne un peu comme celle de SQLite, ce n'est pas un hasard : Fossil est développé par les mêmes personnes, utilise SQLite pour le stockage et est utilisé comme gestionnaire de versions pour ce projet (et d'autres). Fossil n'est donc pas juste un projet sombre dans un coin du Net.

NdM : merci à Etienne Bagnoud pour son journal.

Ce qui m'a séduit c'est d'avoir tout cet attirail de fonctionnalités dans un exécutable de ~800 Kio. Depuis quelques temps, je n'utilise plus qu'un netbook dont le seul critère est l'autonomie. Il y a aussi que je n'ai plus de connexion Internet à mon domicile, mais un abonnement de téléphonie mobile avec données illimitées (limitation de la bande passante à partir de 12 Go/mois). Je recherche donc des outils utilisant un minimum Internet, légers et accessibles sur demande. Fossil est cet outil. Pas besoin de serveur Apache, ou autre, tournant sur ma machine, peu puissante, pour écrire dans un wiki et un système de tickets. Pas besoin d'accès Internet non plus. Un simple fossil ui nom_du_depot et mon navigateur s'ouvre automatiquement sur le wiki et la gestion de ticket du projet. Ctrl-C et tout s'arrête.

Le dépôt, un seul fichier SQLite. Je le copie autre part et j'ai mon projet, avec toutes ses versions, le wiki et les tickets : la sauvegarde est simplifiée.

Pour la partie distribuée de l'outil, je n'ai pas encore testé. Mais les fonctionnalités sont là, Fossil peut tourner en CGI dans un serveur Web plus complet ou fournir son propre serveur (et peu être utilisé depuis inetd). Il a les fonctionnalités "push", "pull", "clone" et "update", mais peut aussi fonctionner en synchronisation automatique, comme un CVS ou un SVN.

Bien entendu, il gère l'importation et l'exportation vers Git, sa prise en main est immédiate (incomparable par rapport à Git) et il y a une gestion d'utilisateurs et de droits très bien faite et complète.

Sur la page de comparaison entre Fossil et GIT, on y trouve la phrase suivante :

The Git model works best for large projects, like the Linux kernel for which Git was designed.

"Le modèle Git est idéal pour des grands projet, comme le noyau Linux pour lequel il a été conçu".

Fossil a vraiment été conçu pour un développeur seul ou une petite équipe ne voulant pas se prendre la tête avec l'administration d'un serveur complet pour héberger trois outils simples (wiki, ticket et DCVS). Et dans ce domaine, Fossil semble vraiment être un réussite.

Je pense que ce projet peut en intéresser plus d'un, je vous invite donc à l'essayer (surtout que sa simplicité déconcertante invite vraiment à le tester).

Aller plus loin

  • # Yep!

    Posté par  (site web personnel) . Évalué à 4.

    Voila une bonne idee : tout les utilitaires de gestion de projet dans un seul executable, qui a le bon gout d'etre leger.

    En parcourant la page du comparatif avec git, j'ai trouve ca :

    The lack of a "rebase" function is considered a feature of Fossil, not a bug.

    Et finalement, ca colle parfaitement avec leur design de utilitaire pour petit projet avec un nombre limité et défini de développeurs qui partagent tout

    Ah, et ca c'est un truc qui m'a rendu heureux :

    git fast-export --all | fossil import --git new-repo.fossil

    Des exemples de projet, pour qu'on ait un petit apercu ?

    • [^] # Re: Yep!

      Posté par  (site web personnel) . Évalué à 3.

      Des exemples de projet, pour qu'on ait un petit apercu ?

      http://chiselapp.com/repositories/

      Et pour les usages de base: http://linuxfr.org/nodes/89202/comments/1314055

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: Yep!

        Posté par  (site web personnel, Mastodon) . Évalué à 9.

        Un exemple perso avec un design personnalisé : https://fossil.kd2.org/garradin/

        (Par contre il n'y a qu'un trunk.)

        Le meilleur exemple reste quand même le fossil de Fossil lui-même : http://fossil-scm.org/index.html/timeline

        Fossil est un DCVS particulièrement pratique je trouve, déjà il est très facile à compiler, le binaire est tout petit et relativement indépendant, ensuite son utilisation est vraiment simple. Là où il faut lire 50 tutos pour Git car son fonctionnement est alambiqué, Fossil est particulièrement facile à appréhender.

        Dans les autres avantages je compte l'utilisation locale : on a un gestionnaire de version complet, en local, sans avoir besoin de connexion au réseau pour gérer le wiki, les tickets, la doc, etc.

        Enfin, son format de stockage, SQLite, le rends particulièrement sûr, car pour corrompre une base SQLite il faut y aller. De plus récupérer et sauvegarder le contenu de la base est relativement aisé.

        Mais c'est aussi le nombre hallucinant de fonctionnalités intégrées :

        • serveur HTTP
        • gestionnaire de tickets
        • wiki
        • téléchargement de tarball et zip
        • documentation du projet intégrée (c'est ce qui est utilisé pour la doc de SQLite par exemple)
        • gestion des accès utilisateurs

        Et dans la version de développement actuelle y'a même aussi une API JSON, accessible non seulement via HTTP mais aussi via la ligne de commande.

        Dans les inconvénients je citerais surtout le fait que Fossil ne connaît que les fichiers, et pas les répertoires, par exemple :

        $ mkdir test
        $ fossil add test
        $ fossil ci test
        fossil: fossil knows nothing about: test
        
        

        Ce qui est plutôt gênant car il n'est pas possible par exemple de faire :

        $ editor templates/test.tpl
        $ fossil ci templates
        
        

        Pour ne commiter que les fichiers dans templates. Car fossil ne sait rien de "templates". De même il n'est pas possible de faire :

        $ fossil ci templates/*
        
        

        Car la commande de commit ne sait gérer que les fichiers qui ont été changé. Ce qui donne donc :

        fossil: file templates/index.tpl has not changed
        
        

        C'est la logique de Fossil qui veut ça. Venant surtout de SVN, mais aussi un peu de Git, je suis relativement habitué à utiliser svn commit répertoire, donc cette logique me paraît un peu contre-intuitive.

        « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

    • [^] # Re: Yep!

      Posté par  . Évalué à 2.

      The lack of a "rebase" function is considered a feature of Fossil, not a bug.
      Et finalement, ca colle parfaitement avec leur design de utilitaire pour petit projet avec un nombre limité et défini de développeurs qui partagent tout

      Le "rebase -i" de git c'est LA feature qui tue et qui te permet de bosser proprement. Et ce même si tu es tout seul. Si tu me l'enlèves je vais être très très malheureux.

      • [^] # Re: Yep!

        Posté par  (site web personnel) . Évalué à 5.

        Ca fait quoi le git rebase?

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: Yep!

        Posté par  . Évalué à 4.

        Les moinsseurs pourraient expliciter en quoi au choix "le rebase ne sert à rien" ou "fossil permet la même souplesse" plutôt que de cliquer sur inutile ?

        Je trouve que le rebase et le merge n'ont pas du tout la même utilité. 99% du temps j'utilise le rebase sur ou entre mes branches locales non publiées alors que le merge s'applique plutôt sur les branches publiques. Du coup dire que le rebase sert à rien quand tu bosses tout seul ou dans une petite équipe j'ai du mal à le comprendre...

        • [^] # Re: Yep!

          Posté par  (site web personnel, Mastodon) . Évalué à 3.

          Les moinsseurs pourraient expliciter en quoi au choix "le rebase ne sert à rien" ou "fossil permet la même souplesse" plutôt que de cliquer sur inutile ?

          Je sais pas moi, le manque d'arguments et d'exemples peut-être ? Le parti-pris ?
          Tu remarqueras d'ailleurs que ton post suivant, donnant les liens étayant judicieusement le fonctionnement et l'intérêt de rebase, est, à l'heure actuelle, noté +4.
          Donc un post qui dit, X est mieux que Y n'est pas suffisant s'il n'est pas suivi de sources ou d'exemples concrets.
          Et puis c'est vendredi et le vendredi, c'est permis :)

        • [^] # Re: Yep!

          Posté par  . Évalué à 4.

          Étant donné que la plupart des utilisateurs de Mercurial se passent de rebase (malgré sa disponibilité sous forme d'une extension), je crois que c'est assez exagéré de présenter ça comme une fonctionnalité tueuse :)

          • [^] # Re: Yep!

            Posté par  . Évalué à 6.

            On peut se passer de tout. 90% des utilisateurs de VCS se satisfont de SVN dont ils ne connaissent pas 30% des possibilités et n'imagine même pas en quoi un DVCS leur faciliterait la vie. Redonnes moi un CVS je continuerais à bosser. Les outils sont là pour apporter du confort et de la facilité mais on peut s'en passer.

            Pouvoir manipuler, réordonner, rejouer les commits et recombiner les branches facilement comme le permet le rebase oui c'est une méga fonctionnalité. Ca t'apporte une flexibilité incroyable pour bosser en local. Ca permet de structurer et mûrir son travail plutôt que de pousser en continu comme un goret sur le repo central. Et ça permet aussi de combiner très facilement branches locales et branches remotes sur des backend pour qui le merge ne veut pas dire grand chose (lire SVN).

            Rebase et merge n'ont pas la même sémantiques. Ils sont complémentaires. Je n'ai jamais bossé avec mercurial, mais le fait que google me sorte des plugins comme rebase (inclus de base) et histedit semble montrer que c'est pas si inutile que ca comme fonctionnalité.

            • [^] # Re: Yep!

              Posté par  (site web personnel) . Évalué à 2.

              On peut se passer de tout. 90% des utilisateurs de VCS se satisfont de SVN dont ils ne connaissent pas 30% des possibilités et n'imagine même pas en quoi un DVCS leur faciliterait la vie. Redonnes moi un CVS je continuerais à bosser. Les outils sont là pour apporter du confort et de la facilité mais on peut s'en passer.

              Au boulot j'utilise ClearCase. Une vraie horreur. En plus, il semble être configuré pour ne pas pouvoir revenir en arrière : une fois que tu as mis à jour les fichiers (ClearCase est file-centric...), si ça pète, tant pis pour toi. Il faut attendre que celui qui a tout fait péter résolve le problème, ou que tu le fasses toi même, parce qu'en attendant, tu peux pas bosser.

              Et je vais dans ton sens, le rebase -i c'est un vrai plaisir à utiliser. Je sais que je peux faire mon goret dans mon coin sans problème (c'est le but d'un DVCS), quand je mettrai tout sur mon repo public je ferai un peu de refactoring de commits pour que ça soit un peu présentable.

            • [^] # Re: Yep!

              Posté par  . Évalué à 3.

              Ca permet de structurer et mûrir son travail plutôt que de pousser en continu comme un goret sur le repo central.

              Heu, je ne vois pas pourquoi ne pas utiliser rebase te force à « pousser en continu comme un goret ». Ou alors git a des limitations que j'ignore.

              Je n'ai jamais bossé avec mercurial, mais le fait que google me sorte des plugins comme rebase (inclus de base) et histedit semble montrer que c'est pas si inutile que ca comme fonctionnalité.

              Je n'ai pas dit que c'était inutile, j'ai dit que ce n'était pas aussi génial que certains semblent l'affirmer. C'est bien pour cela que c'est un plugin optionnel, au même titre que mq et beaucoup d'autres.

          • [^] # Re: Yep!

            Posté par  (site web personnel) . Évalué à 1.

            Ben franchement, je ne me vois pas bosser sous mercurial sans rebase ou mq (sachant qu'au final avec mq on fait du rebase en gros).
            Le rebase est vraiment pour moi une fonctionnalité indispensable. Le problème sans est qu'on se retrouve constamment, lorsqu'on bosse à plusieurs, avec des merge inutiles, juste là au moment où on se synchronise avec le taff des autres.
            Je me souviens d'un post de Torvalds (faudrait que j'arrive à remettre la main dessus) qui expliquait à quelqu'un proposant un patch que son historique était tout pourri, bourré de merge inutiles. Avec un rebase, beaucoup moins de problèmes.
            C'est pas parce que le merge fonctionne qu'on doit l'utiliser n'importe comment. Et, pour moi en tout cas, l'historique est vraiment très important, sa propreté et sa logique aussi.

            • [^] # Re: Yep!

              Posté par  . Évalué à 3.

              A noter la nouvelle fonctionnalité de mercurial : les phases, qui permettent d'avoir des changesets "secrets" tant qu'ils ne sont pas publiés, et donc de faire du rebase dessus sans danger (si j'ai bien compris car je n'ai pas encore essayé).

              http://www.logilab.org/blogentry/88203

            • [^] # Re: Yep!

              Posté par  . Évalué à 5.

              (sachant qu'au final avec mq on fait du rebase en gros)

              Bof. mq est beaucoup plus puissant que rebase, qui se contente de linéariser l'historique. Avec mq, tu empiles des patches que tu peux reprendre à ta guise, etc. Rien que la liste des commandes fournies par mq devrait te faire comprendre qu'il y a un fossé entre les usages des deux extensions.

              • [^] # Re: Yep!

                Posté par  (site web personnel) . Évalué à 2.

                devrait te faire comprendre

                Merci de supposer de ce que je connais ou non...

                Ok, c'était peut-être mal exprimé, mais rebase ou mq, dans les deux cas l'un des objectifs est d'avoir un historique linéaire.

              • [^] # Re: Yep!

                Posté par  . Évalué à 1. Dernière modification le 18 février 2012 à 14:19.

                Je n'utilise pas mercurial du tout, donc je n'irai pas jusqu'à dire que ce que tu dis est faux, mais ça démontre quand même une méconnaissance certaine de la commande git-rebase, surtout rebase -i. Dans la phrase

                Avec mq, tu empiles des patches que tu peux reprendre à ta guise

                on peut faire un s/mq/rebase et ça reste vrai. Pour moi, le principal intérêt de git rebase -i est de pouvoir éditer les patches, les réordonner, les fusionner, bref, faire ce que tu as à faire pour transformer un historique de travail en un patchset bien fichu.

                Après, mq a peut-être — sûrement — des fonctionnalités que rebase n'a pas. La différence est juste moins grande que ce que tu sembles penser.

            • [^] # Re: Yep!

              Posté par  . Évalué à 3.

              Et, pour moi en tout cas, l'historique est vraiment très important, sa propreté et sa logique aussi.

              Disons que lorsque tu bosses avec plein de gens qui ne savent pas forcement se servir a 100% de l'outil, tu dois faire des choix:
              - plein de merge commits parce que plein de gens font des push sans mettre a jour avant
              - un joli historique bien plat parce que tout le monde rebase, mais avec le risque de te retrouver avec plein de revisions qui ne compilent pas...

              Bref, il y a un juste milieu et j'ai comme un doute que tout le monde verifie que toutes leurs revisions continuent a compiler apres un rebase.

          • [^] # Re: Yep!

            Posté par  (site web personnel) . Évalué à 0.

            Pour faire dans l'analogie facile, des centaines de millions d'utilisateurs utilisent toujours Windows, la plupart sous XP, et parmi ceux-là pas mal avec IE6 =]

  • # Fiabilité

    Posté par  (site web personnel) . Évalué à 4.

    Zed Shaw l'utilisait pas mal un moment.
    http://sheddingbikes.com/posts/1276624594.html

    Et puis apparemment fossil lui a flingué un repos.
    http://sheddingbikes.com/posts/1306005291.html

    • [^] # Re: Fiabilité

      Posté par  (site web personnel) . Évalué à 5.

      Et puis apparemment fossil lui a flingué un repos.

      Je ne sais pas ce qui s'est passé, mais ça veut dire qu'il n'avait pas de sauvegarde...

      Quelque-soit le gestionnaire de version, il faut toujours avoir au moins 3 dépôts:

      • le dépôt de travail.
      • le dépôt partagé.
      • le dépôt de secours.

      Dans le vocabulaire de fossil, on parle de checkout au lieu de dépôt de travail, mais le principe est le même.

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: Fiabilité

        Posté par  (site web personnel) . Évalué à 1. Dernière modification le 17 février 2012 à 14:32.

        D'accord pour la sauvegarde, mais si tu bosses sur un truc, tu ne sauvegarde généralement pas ton boulot entre 2 synchros avec le dépot partagé.

        Et lorsque tu "pousse", en général tu dois te mettre à jour des développements extérieurs pour commencer, résoudre les conflits tout ça. Si l'outil te vire tous tes fichiers à ce moment-là, tu es cuit.

        Après il a abandonné, car en voulant résoudre le problème il est tombé sur un autre, bref.

        Le jour ou l'outil se met en travers de ta route et que tu perds ton temps pour tenter de récupérer ton boulot, tu en change je crois. J'espère que ce genre de choses n'arrive plus avec Fossil.

        • [^] # Re: Fiabilité

          Posté par  (site web personnel) . Évalué à 6.

          D'accord pour la sauvegarde, mais si tu bosses sur un truc, tu ne sauvegarde généralement pas ton boulot entre 2 synchros avec le dépot partagé.

          Avec Subversion oui, mais avec les DVCS, c'est différent. Dans le vocabulaire fossil, ça donne:

          • commit: enregistre les modifications du checkout dans le dépôt local.
          • push: envoie les modifications du dépôt local au dépôt distant.
          • pull: reçoit les modifications du dépôt distant au dépôt local.

          Par contre, fossil est par défaut en mode "autosync", cad qu'il fait des pull/push presque tout le temps, ce qui est très pratique quand tu bosses seul, mais c'est un mode à désactiver quand on bosse à plusieurs.

          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: Fiabilité

        Posté par  . Évalué à 6.

        En l'occurence, même avec une sauvgarde, j'aurais un peu de mal avec un gestionnaire qui flingue le dépot suite à une opération du dit gestionnaire. Dans son cas ce n'était pas une erreur système, disque ou autre cause externe à l'outil, mais l'outil en lui même qui à flingué le dépot.

        • [^] # Re: Fiabilité

          Posté par  (site web personnel) . Évalué à 6.

          D'après l'article, je ne comprends pas trop ce qui s'est passé, ni même ce qui a été réellement "flingué", mais ça fait un an que j'utilise fossil avec des versions et des OS différents sans le moindre problème.

          Le gus a eu une réaction émotionnelle je trouve. Au boulot on a déjà eu des checkouts pourris par Subversion ou des situations incompréhensibles avec GIT, pourtant on n'abandonne pas les outils au premier bug.

          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: Fiabilité

      Posté par  . Évalué à 5.

      je connais pas ce gars mais sa reaction est un peu radical. Est ce que il a essaye de demander de l aide? contacter les developeur?
      J'ai eu un collegue une fois qui est est venu me voir avec un repo bzr qui ne marchait plus. En contactant la mailling list on a vite trouve quelqu'un qui a pu aider. Cetait un comportement bizarre de bzr et cela m'etonnerai bien que git ais pas aussi ses propres problemes

    • [^] # Re: Fiabilité

      Posté par  (site web personnel) . Évalué à 6.

      Ce n'est que sa version de l'histoire.

      Il y a aussi le thread sur la ML de Fossil :
      http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg04665.html

      Notamment, le fix de Richard hipp :
      http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg04672.html

      En gros, si j'ai bien compris l'histoire :
      Zed avait travaillé 2 jours sur mongrel sans faire aucun commit. Il reprend le développement le matin avec un 'fossil update', et là, paf, plus aucun fichier.
      Apparemment, il a suffit que quelqu'un crée une branche sur le repo principal, et à cause d'un bug, cela lui a tout effacé.
      Du coup, il s'énerve et abandonne fossil pour tout passer sur github.

      Il faut noter que Richard Hipp a apparemment corrigé le bug 1h environ après son premier message.

      Ça fait vraiment décision coup de tête, surtout que j'ai l'impression qu'il n'a perdu que son travail en cours, et pas tout le repository.

      • [^] # Re: Fiabilité

        Posté par  . Évalué à 4.

        Sans avoir d'avis sur fossil puisque je n'en avais jamais entendu parlé avant aujourd'hui la premier chose que je demande à mes outils c'est d'assurer l'intégrité des mes données quoi qu'il arrive.

        • [^] # Re: Fiabilité

          Posté par  (site web personnel, Mastodon) . Évalué à 8.

          Non voilà le souci décrit sur la ML :

          • A cause d'un bug (corrigé 1h après le message), les fichiers non modifiés ont été supprimés
          • Les fichiers qu'il avait modifié n'ont pas changé et étaient toujours là
          • En essayant de corriger le souci, il a effectué "fossil revert" qui comme son nom l'indique a effacé ses modifs
          • Il a ensuite fait d'autres commandes, l'empêchant ainsi d'utiliser fossil undo après le fossil revert

          Bref, fossil n'est à l'origine d'aucune perte de données, c'est lui qui a effacé ses modifs par erreur. C'est très con mais c'est sa faute.

          « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

        • [^] # Re: Fiabilité

          Posté par  (site web personnel) . Évalué à 3.

          En lisant l'histoire du gus, je me rends compte que ce genre de situation m'est arrivé avec Subversion ou git... Quand on débute, il y a toujours un moment où on fait le boulet parce qu'on n'a pas bien compris le gestionnaire de version!

          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

          • [^] # Re: Fiabilité

            Posté par  . Évalué à 4.

            Personnellement je suis loin d'être un expert en gestionnaire de version. J'utilise git comme client svn parce que je le trouve plus agréable à utiliser (j'aime bien avoir des branches locales, faire des bisects, etc). Loin de moi l'idée que git est mieux ou moins bien que mercurial, fossil, dart ou bazaar, jsute qu'il me va. Mais il m'arrive de ne pas être sur de moi d'arriver à des situation où mon gestionnaire de version commence à m'insulter et, quelques soit le gestionnaire de version je commence toujours par un :

            tar cf projet.tar "${racine_du_projet}"
            
            

            Après quoi on peut discuter, je garde une copie sous la main au cas où. Je ne fais pas ça systématiquement à chaque commit/push/pull/rebase/merge, juste quand je vois que la situation deviens compliquée.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # le livre du fossil

    Posté par  . Évalué à 4.

    J'ai trouvé un peu par hasard un livre (en cours d'écriture) sur Fossil.

    Si ça peut servir à quelqu'un… (je l'ai trouvé en cherchant de la doc sur Google, et je n'ai pas trouvé le lien sur la page d'accueil de Fossil).

    http://www.fossil-scm.org/schimpf-book/index

    Discussions en français sur la création de jeux videos : IRC freenode / #gamedev-fr

  • # Juste par curiosité

    Posté par  (site web personnel) . Évalué à 7.

    C'est quoi ton abonnement bridé au delà de 12 Go par mois ?

  • # More is less

    Posté par  . Évalué à 4.

    Fossil c'est aussi un wiki, un outil de gestion de tickets et une interface Web (et son serveur) dans un seul exécutable [en plus d'être un DVCS]

    Il se veut robuste et fiable, simple

    Soit l'ingénierie logicielle a considérablement évoluée depuis 3 semaines, soit il y a une erreur quelque part.

    • [^] # Re: More is less

      Posté par  . Évalué à 3.

      Au moins il n'a pas besoin de glue...

      Un serveur web minimaliste ça ne nécessite pas beaucoup de ligne de code, une gestion de ticket simple mais efficace guère plus, pour un wiki c'est la même chose. Donc qu'il puisse être robuste et fiable parce qu'étant issue d'un code source unique, en fait d'une seule compilation, ne me paraît pas aberrant.

      • [^] # Re: More is less

        Posté par  . Évalué à 2.

        La philosophie d'Unix est d'écrire des programmes qui font une seule chose et qui le font bien et qui peuvent collaborer entre eux. Je préfère donc un Redmine qui s'appuie sur des programmes éprouvés et dont l'utilisateur à même le choix.

    • [^] # Re: More is less

      Posté par  . Évalué à 2.

      Bah, c'est cohérent.
      Par exemple il est pas modulaire et modifiable facilement, mais il est robuste, fiable et simple.

      Dans l'ingénierie du logiciel, tu fais des choix en fonction de tes exigences, là ils ont choisi de mettre de côté des trucs qui sont souvent mis en avant.

    • [^] # Re: More is less

      Posté par  (site web personnel) . Évalué à 5.

      Soit l'ingénierie logicielle a considérablement évoluée depuis 3 semaines, soit il y a une erreur quelque part.

      Soit l'ingénierie logicielle n'est pas appliquée à la grande majorité des projets. Il y'a des projets qui prouvent qu'il est possible de faire des logiciels sans failles de sécurités (ou pratiquement aucune) comme djdns ou dovecot. SQLite apporte la preuve qu'on peut avoir une batterie de tests couvrants 100% des branches de codes. c'est long et fastidieux de faire un logiciel correcte, mais c'est possible.
      De plus, ce n'est pas un logiciel excessivement compliqué, je pense qu'un serveur comme openldap est nettement plus complexe à développer, pourtant il est robuste et fiable.

      "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

  • # robustesse

    Posté par  . Évalué à 2.

    Ce logiciel paraît bourré de qualités.
    Je suis très tenté de l'utiliser en particulier parce que sqlite est un très bon produit.
    Par contre je me pose des questions sur la robustesse et la fiabilité du produit.
    La grande force de svn est la forme de son repository, à base de fichier, un par commit (un format berkeley db existe aussi mais je ne l'utilise pas).
    Cela permet un très grand nombre de commits (plusieurs millions) mais aussi une sauvegarde incrémental très efficace; en post commit par exemple.
    Est ce que Fossil propose quelque chose d'équivalent ?

    • [^] # Re: robustesse

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Étant donné que Fossil utilise SQLite, l'entièreté du repository est stockée dans une base SQLite, c'est donc un seul fichier binaire, en apparence pour le système de fichier en tout cas.

      Donc rien à voir avec les fichiers indépendants de SVN. Après le repository est en général très léger quand même, sauf si tu y met plein de binaire.

      « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

      • [^] # Re: robustesse

        Posté par  . Évalué à 2.

        Merci pour les précisions.

        Quelque soit l'outil, la taille du repository est au moins égale à la taille des données. Et le cas que j'envisageais était de l'ordre de quelques giga. Donc ça va pas le faire avec un seul gros fichier.

        J'essayerai fossil à l’occasion pour un cas plus petit.

        • [^] # Re: robustesse

          Posté par  (site web personnel) . Évalué à 1.

          Donc ça va pas le faire avec un seul gros fichier.

          Pourquoi? Tu stockes tes dépôts sur du fat32?

          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

          • [^] # Re: robustesse

            Posté par  (site web personnel) . Évalué à 3.

            Ou alors simplement que si ton fichier fais quelques giga c'est quand même plus lourd de se déplacer dedans, non ?

            • [^] # Re: robustesse

              Posté par  . Évalué à 2.

              Non :D

              Envoyé depuis mon lapin.

            • [^] # Re: robustesse

              Posté par  (site web personnel) . Évalué à 4.

              Un dépôt fossil est une base sqlite, donc les données sont indexées.

              Pour les performances globales de fossil, tu peux consulter cette page: http://fossil-scm.org/index.html/doc/trunk/www/stats.wiki

              D'une manière générale, fossil est fait pour les petits et moyens projets, avec des équipes à taille humaine dont les membres se connaissent bien et quelques contributeurs externes occasionnels, quand l'installation et la maintenance d'un site web, d'un bug tracker, d'un repository browser prennent trop de temps aux développeurs.

              Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

          • [^] # Re: robustesse

            Posté par  . Évalué à 2.

            Pourquoi pas dans l'absolu mais ici je pense à la réplication fil de l'eau.
            Avec svn, un commit = 2 fichiers.
            donc tu peux copier en lieu sûr ces deux petits fichiers en action post commit. C'est très scalable.
            S'il fallait déplacer tout le repository à chaque fois, ce serait inenvisageable.
            Cela tient lieu de réplica, en cas de perte de disque par exemple, mais aussi de sauvegarde, robuste aux erreurs humaines, car tu peux recréer ton repository en remontant avant l'erreur.

        • [^] # Re: robustesse

          Posté par  (site web personnel, Mastodon) . Évalué à 0.

          Quelque soit l'outil, la taille du repository est au moins égale à la taille des données.

          Ah ? Tu peux expliquer ?
          Normalement, un logiciel de gestion de versions ne stocke-t-il pas seulement des deltas d'une révision à une autre (hormis pour les binaires off course) ?

          Et le cas que j'envisageais était de l'ordre de quelques giga. Donc ça va pas le faire avec un seul gros fichier.

          Ben un DVD rippé, ça doit bien faire dans les 4Go d'ISO mon bon monsieur et le tout dans un seul fichier.
          Franchement, blague à part, je vois pas ce qui est gênant d'avoir un fichier de quelques Go ? S'il y a un problème, ça me fout les boules, je fais des dump d'un référentiel Subversion de 10Go toutes les nuits au boulot pour sauvegarde ;)

          • [^] # Re: robustesse

            Posté par  . Évalué à 3.

            Je répondais à BohwaZ qui me disait "le repository est en général très léger".
            Le repository est au moins aussi grand que les données que tu y stockes, il n'y a pas d'opération magique :)
            donc si mes données font qques giga, le repository fera au moins ces qques giga.

            Pour le reste, cf mon commentaire juste au dessus sur le réplication.
            Pour l'appliquer à ton exemple, je vais pas faire un transfert de 10Go sur un site distant à chaque commit.

            • [^] # Re: robustesse

              Posté par  (site web personnel) . Évalué à 3.

              Le repository est au moins aussi grand que les données compressées que tu y stockes

              Matthieu Gautier|irc:starmad

            • [^] # Re: robustesse

              Posté par  (site web personnel, Mastodon) . Évalué à 2.

              Ce que je voulais dire c'est que Fossil ajoute très peu d'overhead par rapport à juste la présence des fichiers.

              Après un DVCS c'est quand même pas conçu pour stocker des gigas de données normalement, ou alors se tourner vers des trucs comme Git pour ça, et encore.

              Quand tu vois que SVN n'arrivait pas gérer 1Go de repository déjà... (avec plusieurs dizaines milliers de commits quand même), à mon avis faut quand même pas se reposer dessus pour versionner du binaire. Par exemple versionner des PSD j'ai déjà essayé, c'est rigolo au début, mais ça devient vite ingérable.

              « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

              • [^] # Re: robustesse

                Posté par  . Évalué à 4.

                Après un DVCS c'est quand même pas conçu pour stocker des gigas de données normalement, ou alors se tourner vers des trucs comme Git pour ça, et encore.

                Qu'est ce qui t'en empêche ? Même sans versionner du binaire sur des projets conséquents ça monte très très vite.

                Quand tu vois que SVN n'arrivait pas gérer 1Go de repository déjà... (avec plusieurs dizaines milliers de commits quand même),

                Faut pas déconner. Des projets gérés sous SVN avec entre 100000 et 2000000 de commits avec quelques dizaines de giga y'en a des pelletés.

              • [^] # Re: robustesse

                Posté par  . Évalué à 3.

                Bah non, je vois pas.
                J'ai déjà vu des repositories svn de plusieurs giga, plusieurs dizaine de millier de fichiers et autant de commit.
                À l'usage, SVN est robuste.

              • [^] # Re: robustesse

                Posté par  (site web personnel) . Évalué à 3.

                Quand tu vois que SVN n'arrivait pas gérer 1Go de repository déjà...

                Sur un 386 avec 2mo de ram?

                Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                • [^] # Re: robustesse

                  Posté par  . Évalué à 1.

                  Oui

                • [^] # Re: robustesse

                  Posté par  . Évalué à 3.

                  Et 512Mo d'espace disque
                  Euh...

                • [^] # Re: robustesse

                  Posté par  (site web personnel, Mastodon) . Évalué à 2.

                  Nan sur un quad core, avec des dizaines de dévs qui bossaient dessus au quotidien.

                  C'était utilisable hein, juste méga lent... C'est un des gros défauts de SVN je trouve, c'est super lent au niveau réseau.

                  « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

                  • [^] # Re: robustesse

                    Posté par  . Évalué à 1.

                    En même temps, un quadcore av3ec une dizaine de devs dessus, ça doit être méga lent tout court, pas besoin de svn.

                    →[]

                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.