Le Mar 11 Avril 2006 22:01, Jérôme Marant a écrit : > Pierre Habouzit <madcoder@debian.org> 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 madcoder@debian.org OOO http://www.madism.org
Attachment:
pgpogL3680y3S.pgp
Description: PGP signature