[HS] SCM distribués
Bonjour, Ca fait déjà quelque temps que je teste des systèmes de contrôle de version (SCM) distribués mais je n'arrive pas à me fixer sur un en particulier (le sujet n'est pas ici le pour ou contre les SCM distribués). J'ai déjà laissé tomber tla trop complexe pour les tâches à accomplir et son successeur bazaar (que Canonical a cessé de supporter), darcs qui est trop lent à mon goût. Mes critères de choix sont la rapidité, la possibilité de partager un référentiel par HTTP ou FTP de manière efficace (sans serveur dédié), le support des renommages lors des merge. Ce qui élimine SVK et monotone (ce dernier étant très lent par ailleurs). Il reste donc grosso modo les trois suivants: git/cogito: efficace, partage efficace par HTTP via packed objects, référentiel très compact Mais: interface un peu plus compliquée, sauf via cogito mercurial: efficace, interface simple, écrit en python Mais: pas de support merge+rename, pas de partage efficace par HTTP sauf via un serveur défié bzr: interface simple, écrit en python Mais: lent, référentiel peu compact, développé par Canonical (contributions nécessitent assignation de copyright) Quelqu'un a-t'il une expérience avec ces trois SCM? Merci. -- Jérôme Marant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [HS] SCM distribués
Le Mar 11 Avril 2006 16:23, Jérôme Marant a écrit : Bonjour, Ca fait déjà quelque temps que je teste des systèmes de contrôle de version (SCM) distribués mais je n'arrive pas à me fixer sur un en particulier (le sujet n'est pas ici le pour ou contre les SCM distribués). J'ai fait le même genre de recherches à une époque, et mon constat a été que à peu près aucun SCM distribué avait à la fois de bonnes propriétés fonctionnelles, et restaient simples à utiliser. J'ai utilisé arch/tla, mes dotfiles sont versionnés avec darcs. Je ne connais pas mercurial et bzr. Mon constat est que arch, darcs et cie, ça fait mal à la tête de les utiliser. Mon autre constat est qu'en fait, les gens utilisent le plus souvent les SCM distribués pour pouvoir faire des checkouts locaux/offline, mais que la repository officielle du projet reste centrale, et que très rarement des commits/merge se font entre repositories satellites. Malheureusement aucun SCM que je connaisse n'utilise ce genre d'infos pour simplifier ses algos de merge, et on se retrouve donc avec du coté des SCM un trade-off complexité de l'interface/fonctionnalités qui n'a pas de solution satisfaisante. Bien sur, je fais sans doute du wishful thinking et tu vas me dire que si si tu as besoin de SCM vraiment distribué avec plusieurs upstreams, dans ce cas, il va falloir te résoudre à des compromis, parce que le SCM hait la symétrie, et que donc si le SCM ne peut faire aucune hypothèse pour casser la symétrie, c'est à l'utilisateur du SCM de faire remonter les informations pour casser la symétrie et permettre au SCM de résoudre les conflits automatiquement, ce qui se traduit par ces interfaces lourdes, peu intuitives que certains SCM ont ..ooOO( tla ) -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpVLEz6Y8Utr.pgp Description: PGP signature
Re: [HS] SCM distribués
Julien Danjou [EMAIL PROTECTED] writes: On Tue, Apr 11, 2006 at 04:23:04PM +0200, Jérôme Marant wrote: mercurial: efficace, interface simple, écrit en python Mais: pas de support merge+rename, pas de partage efficace par HTTP sauf via un serveur défié Les checkout sont aussi tres tres gros a ce que je vois en l'utilisant (mais peut-etre mal ?) avec le repository de Xen. (pour 22 M de source, 150 M de checkout). Le checkout rappatrie tout l'historique. C'est peut-être inévitable. Merci pour l'information. -- Jérôme Marant
Re: [HS] SCM distribués
Raphael Hertzog [EMAIL PROTECTED] writes: On Tue, 11 Apr 2006, Jérôme Marant wrote: git/cogito: efficace, partage efficace par HTTP via packed objects, référentiel très compact C'est vrai référentiel très compact ? De ce que j'avais compris, git a commencé comme un simple archivage historique de répertoire/fichiers (via une empreinte SHA1 identifiant implicitement la version) ... ce qui fait qu'il dupliquait énormément d'informations. Ca a changé ? J'ai mal compris ? Oui, ça a changé. En fait, c'est le plus compact qui soit, actuellement. Ce ne sont plus que des delta qui sont stockés, plus certaines optimisations. mercurial: efficace, interface simple, écrit en python Mais: pas de support merge+rename, pas de partage efficace par HTTP sauf via un serveur défié bzr: interface simple, écrit en python Mais: lent, référentiel peu compact, développé par Canonical (contributions nécessitent assignation de copyright) Quelqu'un a-t'il une expérience avec ces trois SCM? J'en ai entendu du bien des trois mais je n'ai utilisé qu'un tout petit peu le troisième parce que pas mal de contributeurs Debian/Ubuntu l'utilisent. OK, merci. -- Jérôme Marant
Re: [HS] SCM distribués
Pierre Habouzit [EMAIL PROTECTED] writes: Le Mar 11 Avril 2006 16:23, Jérôme Marant a écrit : Bonjour, Ca fait déjà quelque temps que je teste des systèmes de contrôle de version (SCM) distribués mais je n'arrive pas à me fixer sur un en particulier (le sujet n'est pas ici le pour ou contre les SCM distribués). J'ai fait le même genre de recherches à une époque, et mon constat a été que à peu près aucun SCM distribué avait à la fois de bonnes propriétés fonctionnelles, et restaient simples à utiliser. J'ai utilisé arch/tla, mes dotfiles sont versionnés avec darcs. Je ne connais pas mercurial et bzr. Mon constat est que arch, darcs et cie, ça fait mal à la tête de les utiliser. Mal à la tête ? Pour tla, je te l'accorde. Mais darcs est plutôt très simple, non ? Mon autre constat est qu'en fait, les gens utilisent le plus souvent les SCM distribués pour pouvoir faire des checkouts locaux/offline, mais que la repository officielle du projet reste centrale, et que très rarement des commits/merge se font entre repositories satellites. C'est déjà bien pour ça. Et aussi pour pouvoir partager l'historique très facilement. Malheureusement aucun SCM que je connaisse n'utilise ce genre d'infos pour simplifier ses algos de merge, et on se retrouve donc avec du coté des SCM un trade-off complexité de l'interface/fonctionnalités qui n'a pas de solution satisfaisante. Tout dépend des besoins en la matière. L'approche de Linus avec git, toujours pragmatique, est de couvrir plutôt les cas les plus fréquents. Bien sur, je fais sans doute du wishful thinking et tu vas me dire que si si tu as besoin de SCM vraiment distribué avec plusieurs upstreams, dans ce cas, il va falloir te résoudre à des compromis, parce que le SCM hait la symétrie, et que donc si le SCM ne peut faire aucune hypothèse pour casser la symétrie, c'est à l'utilisateur du SCM de faire remonter les informations pour casser la symétrie et permettre au SCM de résoudre les conflits automatiquement, ce qui se traduit par ces interfaces lourdes, peu intuitives que certains SCM ont ..ooOO( tla ) Je suis d'accord. Mais tout est question de compromis, à mon sens. Merci. -- Jérôme Marant
Re: [HS] SCM distribués
Le Mar 11 Avril 2006 22:01, Jérôme Marant a écrit : Pierre Habouzit [EMAIL PROTECTED] writes: Le Mar 11 Avril 2006 16:23, Jérôme Marant a écrit : Bonjour, Ca fait déjà quelque temps que je teste des systèmes de contrôle de version (SCM) distribués mais je n'arrive pas à me fixer sur un en particulier (le sujet n'est pas ici le pour ou contre les SCM distribués). J'ai fait le même genre de recherches à une époque, et mon constat a été que à peu près aucun SCM distribué avait à la fois de bonnes propriétés fonctionnelles, et restaient simples à utiliser. J'ai utilisé arch/tla, mes dotfiles sont versionnés avec darcs. Je ne connais pas mercurial et bzr. Mon constat est que arch, darcs et cie, ça fait mal à la tête de les utiliser. Mal à la tête ? Pour tla, je te l'accorde. Mais darcs est plutôt très simple, non ? oui, et non. pour mes dotfiles, c'est parfait. Mais lorsque tu veux gérer des branches, ça fait mal à la tête. développer à plusieurs avec est sans doute ingérable. mais pour moi qui met à jour mes dotfiles sur pleins de machines, pas toujours à jour en checkout, etc... c'est royal, *ET* simple. Mais je ne l'utiliserais jamais pour un projet à plusieurs. Malheureusement aucun SCM que je connaisse n'utilise ce genre d'infos pour simplifier ses algos de merge, et on se retrouve donc avec du coté des SCM un trade-off complexité de l'interface/fonctionnalités qui n'a pas de solution satisfaisante. Tout dépend des besoins en la matière. L'approche de Linus avec git, toujours pragmatique, est de couvrir plutôt les cas les plus fréquents. Je ne connais pas du tout git, ça n'existait pas lorsque j'avais regardé les SCM (enfin, c'était balbutiant). Je ne sais donc pas très bien me prononcer. Bien sur, je fais sans doute du wishful thinking et tu vas me dire que si si tu as besoin de SCM vraiment distribué avec plusieurs upstreams, dans ce cas, il va falloir te résoudre à des compromis, parce que le SCM hait la symétrie, et que donc si le SCM ne peut faire aucune hypothèse pour casser la symétrie, c'est à l'utilisateur du SCM de faire remonter les informations pour casser la symétrie et permettre au SCM de résoudre les conflits automatiquement, ce qui se traduit par ces interfaces lourdes, peu intuitives que certains SCM ont ..ooOO( tla ) Je suis d'accord. Mais tout est question de compromis, à mon sens. oui mais justement, tu regrettais soit la complexité, soit le manque de fonctionnalités, mon point est justement que c'est un choix du à la généralité des problèmes (inexistants dans la réalité) que les projets de SCM cherchent à résoudre, et que donc il ne faut sans doute pas s'attendre à des miracles ;) -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpvR5uOwtFn8.pgp Description: PGP signature
Re: [HS] SCM distribués
Pierre Habouzit [EMAIL PROTECTED] writes: Mal à la tête ? Pour tla, je te l'accorde. Mais darcs est plutôt très simple, non ? oui, et non. pour mes dotfiles, c'est parfait. Mais lorsque tu veux gérer des branches, ça fait mal à la tête. développer à plusieurs avec est sans doute ingérable. mais pour moi qui met à jour mes dotfiles sur pleins de machines, pas toujours à jour en checkout, etc... c'est royal, *ET* simple. Mais je ne l'utiliserais jamais pour un projet à plusieurs. Je n'avais pas cette impression. Merci de partager la tienne. ... Bien sur, je fais sans doute du wishful thinking et tu vas me dire que si si tu as besoin de SCM vraiment distribué avec plusieurs upstreams, dans ce cas, il va falloir te résoudre à des compromis, parce que le SCM hait la symétrie, et que donc si le SCM ne peut faire aucune hypothèse pour casser la symétrie, c'est à l'utilisateur du SCM de faire remonter les informations pour casser la symétrie et permettre au SCM de résoudre les conflits automatiquement, ce qui se traduit par ces interfaces lourdes, peu intuitives que certains SCM ont ..ooOO( tla ) Je suis d'accord. Mais tout est question de compromis, à mon sens. oui mais justement, tu regrettais soit la complexité, soit le manque de fonctionnalités, mon point est justement que c'est un choix du à la généralité des problèmes (inexistants dans la réalité) que les projets de SCM cherchent à résoudre, et que donc il ne faut sans doute pas s'attendre à des miracles ;) Entièrement d'accord. -- Jérôme Marant
Re: [HS] SCM distribu??s
On Tue, Apr 11, 2006 at 09:55:54PM +0200, J??r??me Marant wrote: Raphael Hertzog [EMAIL PROTECTED] writes: On Tue, 11 Apr 2006, J??r??me Marant wrote: git/cogito: efficace, partage efficace par HTTP via packed objects, r??f??rentiel tr??s compact C'est vrai r??f??rentiel tr??s compact ? De ce que j'avais compris, git a commenc?? comme un simple archivage historique de r??pertoire/fichiers (via une empreinte SHA1 identifiant implicitement la version) ... ce qui fait qu'il dupliquait ??norm??ment d'informations. Ca a chang?? ? J'ai mal compris ? Oui, ??a a chang??. En fait, c'est le plus compact qui soit, actuellement. Ce ne sont plus que des delta qui sont stock??s, plus certaines optimisations. Pas exactement. En fait sous git il y a 2 repr?sentations des m?mes donn?es: - un objet= une signature SHA1=un fichier dans .git/objects/xx/$SHA1 ou xx sont les deux premiers caract?res de la signature SHA1 dudit objet en hexad?cimal. - toute une s?rie d'objets compact?s dans un ensemble de deux fichiers (pack-$SHA1.pack et pack- $SHA1.idx) dans .git/objects/pack; dans ces fichiers, on stocke une version puis les diff?rences avec d'autres versions (pas forc?ment la plus r?cente ou la plus vieille, voir les heuristiques). Il y a une limite sur le longueur des cha?nes de diff?rences pour des raisons de performance. Le format des pack est expliqu? plus ou moins dans le source de git dans Documentation/technical/, le fichier pack-heuristiscs.txt est, disons, int?ressant. Franchement depuis que je me suis habitu? ? git, je trouve que tous les autres syst?mes ont des limites. En particulier l'un des d?veloppeurs du noyau fait des git-rebase pour ?viter que l'arborescence devienne inextricable: http://www.ussg.iu.edu/hypermail/linux/kernel/0601.1/0172.html aucun autre SCM n'offre, que je sache, cette possibilit?. Elle est un peu dangereuse (c'est en un certain sens r??crire l'histoire) mais c'est une libert? de plus. git est un peu d?licat ? manipuler par certains c?t?s, mais son traitement des branches, le fait de pouvoir partager partiellement les r?f?rentiels (alternate), qui sauve pas mal d'espace disque, et d'autres caract?ristiques en font mon SCM pr?f?r?. Par certains c?t?s, il a largement d?pass? bitkeeper et les interfaces graphiques arrivent (qgit semble progresser assez vite mais je ne le suis pas de pr?s): j'aime bien gitk pour regarder l'historique, les commandes de base de git et vi me suffisent pour le reste. En plus la vitesse de git est assez ph?nom?nale, il est tout ? fait utilisable sur une machine de 5 ans si la m?moire est suffisante. Bien s?r, un disque rapide ne fait pas de mal. Ceci dit, quand j'ai commenc? sous git en Juin dernier (conversion d'un r?f?rentiel BitKeeper en essayant de pr?server l'histoire), ce n'?tait pas encore vraiment au point. Je crois que ?a ne fait que 2 ou 3 mois que git marche vraiment bien (par exemple que les tags des versions sont transmis automatiquement par ?git pull?) et que la doc est devenue compr?hensible. Gabriel
Re: [HS] SCM distribués
Jérôme Marant wrote: Julien Danjou [EMAIL PROTECTED] writes: On Tue, Apr 11, 2006 at 04:23:04PM +0200, Jérôme Marant wrote: mercurial: efficace, interface simple, écrit en python Mais: pas de support merge+rename, pas de partage efficace par HTTP sauf via un serveur défié Les checkout sont aussi tres tres gros a ce que je vois en l'utilisant (mais peut-etre mal ?) avec le repository de Xen. (pour 22 M de source, 150 M de checkout). Le checkout rappatrie tout l'historique. C'est peut-être inévitable. Ça paraît assez courant pour les SCM distribués. Passé un temps, mercurial était beaucoup plus compact que git/cogito. Ce dernier s'est beaucoup amélioré avec les pack (à demander manuellement par contre, si je me souviens bien) et il est repassé devant. Il y a des patches pour mercurial pour améliorer ce point, mais ils ne sont pas encore tout à fait finalisés. Un autre intérêt de mercurial (qui découle de son langage de programmation), c'est qu'il est dispo sur windows, mac et de nombreux unix. Ce n'est pas le cas de git/cogito. Ça peut parfois avoir son importance. La dernière version de mercurial (0.8.1) intègre l'extension mq (un système quilt-like comme il en existe aussi pour git/cogito). Ça permet de travailler en faisant/défaissant ses patches localement tout en suivant les mises à jour upstream. A+ Vincent Note: le package debian 0.8.1 est sur ma page web en attendant que mon sponsor le mette dans la distrib... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
