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
- Journal à l'origine de la dépêche (161 clics)
- Présentation de fossil (457 clics)
# Yep!
Posté par rakoo (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 :
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 :
Des exemples de projet, pour qu'on ait un petit apercu ?
[^] # Re: Yep!
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
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 BohwaZ (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 :
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 :
Ce qui est plutôt gênant car il n'est pas possible par exemple de faire :
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 :
Car la commande de commit ne sait gérer que les fichiers qui ont été changé. Ce qui donne donc :
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 ckyl . Évalué à 2.
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 devnewton 🍺 (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 ckyl . Évalué à 8.
http://book.git-scm.com/4_rebasing.html
http://book.git-scm.com/4_interactive_rebasing.html
C'est aussi utile quand tu as plusieurs branches en locale pour faire avancer tes suites de patchs par rapport à d'autres branches, qu'en mode interactif qui de permet d'éditer des commits, leur message de commit ou même de changer l'ordre de tes patchs.
Revenir en arrière une fois que tu y as gouté ca fait très mal.
[^] # Re: Yep!
Posté par CrEv (site web personnel) . Évalué à 1.
http://lmgtfy.com/?q=git+rebase&l=1
[^] # Re: Yep!
Posté par Victor . Évalué à 4.
iink: information is not knowledge
[^] # Re: Yep!
Posté par ckyl . É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 Blackknight (site web personnel, Mastodon) . Évalué à 3.
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 Antoine . É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 ckyl . É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 rakoo (site web personnel) . Évalué à 2.
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 Antoine . Évalué à 3.
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 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 CrEv (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 wilk . É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 Antoine . Évalué à 5.
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 CrEv (site web personnel) . Évalué à 2.
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 laarmen . É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
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 Littleboy . Évalué à 3.
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 rakoo (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 bathizte (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 devnewton 🍺 (site web personnel) . Évalué à 5.
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:
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 bathizte (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 devnewton 🍺 (site web personnel) . Évalué à 6.
Avec Subversion oui, mais avec les DVCS, c'est différent. Dans le vocabulaire fossil, ça donne:
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 EdB . É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 devnewton 🍺 (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 ord . É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 Maz (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 ckyl . É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 BohwaZ (site web personnel, Mastodon) . Évalué à 8.
Non voilà le souci décrit sur la ML :
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 devnewton 🍺 (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 barmic . É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 :
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 jseb . É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 libera / #gamedev-fr
# Juste par curiosité
Posté par Bruce Le Nain (site web personnel) . Évalué à 7.
C'est quoi ton abonnement bridé au delà de 12 Go par mois ?
[^] # Re: Juste par curiosité
Posté par s[e]th & h[o]lth (site web personnel) . Évalué à -1.
CTRL+F 12 Go : Merde, j'aimerais bien le savoir aussi...
[^] # Re: Juste par curiosité
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
C'est Swisscom, un opérateur suisse, il y'a 2G avec l'abo téléphonie et j'ai pris une extension 10G. Ça me revient a environ 100€ par mois avec des appels et messages gratuits.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
# More is less
Posté par Kerro . Évalué à 4.
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 Marotte ⛧ . É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 Romuald Delavergne . É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 Victor . É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 Etienne Bagnoud (site web personnel) . Évalué à 5.
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 steph1978 . É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 BohwaZ (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 steph1978 . É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 devnewton 🍺 (site web personnel) . Évalué à 1.
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 CrEv (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 yellowiscool . Évalué à 2.
Non :D
Envoyé depuis mon lapin.
[^] # Re: robustesse
Posté par devnewton 🍺 (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 steph1978 . É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 Blackknight (site web personnel, Mastodon) . Évalué à 0.
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) ?
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 steph1978 . É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 GaMa (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 BohwaZ (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 ckyl . Évalué à 4.
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.
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 steph1978 . É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 devnewton 🍺 (site web personnel) . Évalué à 3.
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 steph1978 . Évalué à 1.
Oui
[^] # Re: robustesse
Posté par windu.2b . Évalué à 3.
Et 512Mo d'espace disque
Euh...
[^] # Re: robustesse
Posté par BohwaZ (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 claudex . É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.