Re: [HS] SCM distribués
Jérôme Marant wrote: Pierre Habouzit [EMAIL PROTECTED] writes: 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. J'utilise darcs quotidiennement et j'en suis ravi. Pour des petits projets (~ 30 fichiers) sans trop de divergences (e.g. un reponsable de composant, les collègues se synchronisant ou développant des correctifs) c'est à mon avis idéal. Je ne peux plus m'en passer et j'ai converti deux personnes au taf. Ceci dit c'est vrai qu'il est extrêmement lent, et certaines fonctionnalités manquent. Par exemple le fait de refuser de puller un patch peut rendre d'autres patches inappliquables, mais cette dépendance n'est pas visualisable, si ce n'est que le nombre de patches possiblement appliquables diminue. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [HS] SCM distribués
Vincent Danjean [EMAIL PROTECTED] writes: 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. Oui. Mais ça ne fait pas partie de mes critères pour le moment. 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. Il manque surtout un équivalent aux packed objects (les bundles sont une solution ad-hoc), bon support du rappatriement en pur HTTP (old-http n'est pas conseillé), et surtout la prise en compte des renommages de fichiers lors des merges (reporté après 1.0). Encore une fois, ce sont des critères qui me sont très personnels. -- Jérôme Marant
Re: [HS] SCM distribu??s
Gabriel Paubert [EMAIL PROTECTED] writes: 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. ... 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. Merci de ton retour d'expérience. -- Jérôme Marant
