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 madcoder@debian.org OOO http://www.madism.org
Attachment:
pgpq_vG0jbwOe.pgp
Description: PGP signature