marmoute a écrit 88 commentaires

Il y a une petite flopée d'autre transformation faite sous windows, par example les "." en fin de fichier ("toto." → "toto") et les espaces en début de fichier (" toto" → "toto"). Cette catégorie de blague était déjà géré par Mercurial.

Les nouveautés sont l'exploitation des nom courts (suggérée par quelqu'un de chez Microsoft, quand ils ont été informés de la CVE) et la faille sur les caractères Unicode ignorés par Mac os X (trouvée par Matt Mackall pendant une longue soirée d'hiver.)

Yop, ça tabasse bien au niveau performance.

source

Par contre je ne sais pas trop d'où tu sors ton chiffre de 2.5 millions mais mon petit doigt que dit qu'il est faux.

Mercurial n'est pas plus limité que git. Ton exemple Rebase est fournit avec Mercurial depuis 2008…

La quantité de méconnaissance dans ce débat l'aide beaucoup à virer au troll. (J'ai entendu mon coussin à entendu chef le coiffeur deux personnes qui disait que Emacs n'avait pas de coloration syntaxique. C'est sûrement vrai!)

Sous hg pas moyen de voir l'historique remote à moins de pull ??
Hg pull = git fetch.

hg incoming # command vielle de 8 ans

Pas de rebase par défaut (c'est un plugin)
[…]
Après, je ne sais pas comment est supporté le rebase aujourd'hui pour Hg

Rebase fait parti de la distribution standard. Il à la même niveau de support que le reste de Mercurial. Il est ajouté 10 lettre dans ta config pour y avoir accéés.

Rebase a un bon support dans Mercurial et s'en sort même mieux que git dans des cas tordus ou tu veux préserver des merges et ne pendre qu'une partie de l'historique (rare, certes)

Déjà y'a pas d'index par défaut avec Hg. Je l'avais oublié celle-là [… remarque wtf the codeur java …]

Jamais comprit l’intérêt d'avoir un concept supplémentaire pour l'index quand on peut faire exactement là même chose avec de bon outils pour amend le changeset en cours.

Pis c'est tellement logique de rajouter à l'index pour marquer des conflit comme résolus pour des gens qui ont l'habitude d'utiliser un commande svn resolve, pour "resoudre" un conflit

Mercurial à interface utilisateur simple et claire pour ça. Rien particulièrement différent chez tout le monde.

et pas de config sur la branche pour pull (merge ou rebase).

Faux, il est possible de spécifier une branche particulière dans tes path (équivalent de git remote)

Bref: ce qui est bien avec de débat c'est que chacun à une connaissance superficiel de l'autre outil mais est quand même persuadé qu'il est inférieur.

L'article explique que les problèmes de performance sont lié à deux choses:
- La quantité des changesets (C'est moins gros que plusieurs millions mais plein quand même)
- La quantité de fichiers versionnés

Chacune de ses dimensions va ralentir un aspect de l'outil. <hg|git> status ne va pas être affecté par le nombre de changesets mais par le nombre de fichiers. À l'inverse <git|hg> pull ne va pas vraiment être affecté par le nombre de fichier total mais par le nombre de changesets/changement à synchroniser.

Chacune des deux extensions présentées améliorent fortement une dimension dans ce sens. hgwatchman accélère la supervision des fichiers de Facebook. remotefilellog améliore le transfert des changesets créés toute les jours.

Un certain nombre d'autre modifications ont également été faite upstream. Par exemple depuis 4 versions hg update (équivalent de git checkout) est parallélisé, le calcul du contenu et l'écriture sur disque de plusieurs fichiers sont réalisés en même temps. Cela peut donner des améliorations de performance assez drastique quand on utilise des machines à plusieurs dizaines de cœurs pour des mises à jours de plusieurs milliers de fichiers.

Par ailleurs un certain nombre d'opération dans git prennent en compte l'intégralité du dépôt, comme le "packing" ou la "garbage collection". C'est opération sont donc de plus en plus lentes au fur et à mesure que le dépôt grossi. Si on prend en compte le fait que ces opérations ont des races conditions entre elle et avec un certain nombre de command de base (ceci n'est pas une blague) ça ne donne pas très envie de les voir s'étaler dans la durée. Mercurial à un format de stockage "en ajout uniquement" qui ne souffre pas de ce genre de problème tout en garantissant un stockage efficace en place et en temps de restauration.

Pour finir, je rappel que Mercurial n'a pas besoin de plusieurs clone pour utiliser plusieurs branches. Il me semble que c'est bazaar qui suit ce modèle.

Je ne sais pas si "ça sent mal barre", je dirais que ça dépend surtout de la volonté des devs Mercurial (Matt Mackall principalement) d'admettre qu'unicode est une meilleure solution pour représenter du texte que de trimbaler des chaînes d'octets aveuglément.

Il y a en fait deux sujets unicode. L'un d'eux est concernent les noms de fichier, il est patrouillé par des trolls et chaque faction à de bon argument.

Le second sujet est le stockage de fichier commité. Et j'ai vraiment du mal à voir quelqu'un argumenté que le contenu d'un fichier est autre chose qu'un énorme blob de bytes du point de vu du DVCS ;-)

La PEP460 est un grand pas en avant sur ce front là. Et les gens qui s'intéressent à ces questions dans la communauté Mercurial s'en forte déjà les mains.

Il y a des gens chez Google qui s'intéressent à Mercurial sur python trois. Donc ça devrait arrivé dans les années qui viennent.

Mercurial a un système de branche depuis 2005 soit la première année. Je ne sais pas trop d'où te viens ce souvenir d'un besoin de branche par clone obligatoire. Il me semble que ce comportement est plutôt du domaine de Bazaar.

Les opérations bas niveau (accéés disque) ou assez intensives sont codés en C parce que cpython n'est pas bon pour ça. Ce qui donne 5% du code C avec 95% de logique en python facile à étendre et à réécrire quand besoin. C'est plutôt une cas d'école de bonne utilisation de python qu'une lente réécriture intégrale en C.

Le temps dans le développement des DVCS passent étonnement lentement. Par exemple Mercurial a mis un certain temps à rattraper git rebase, mais une fonctionnalité rendant plus sûre cette réécriture introduite il y a 2 ans par Mercurial est toujours absente de git. Malgré que les développeurs de git s'y intéressent

Bref, les deux outils se réapproprient les bonnes idées lentement mais sûrement depuis 8 ans et j'espère que bien que cela continue.

En regardant un peu plus loin il y à moyen d'être un peu plus enthousiaste.

Certes l'extension remotefilellog tel quel vise une petit niche, mais elle est aussi un premier pas vers des applications plus accessible. Une étape supplémentaire serait de remplacé le serveur memcache par un server mercurial classique. Un peu moins performance mais mise en place transparente pour l'utilisateur final. On peu pousser là logique encore un peu plus loin en faisant des clones paresseux: Du clone le minimum et tu peux utiliser ton dépôt immédiatement pendant qu'un processus continue de le remplir en tâche de fond. Bref cette extension est à la fois un pas important dans la bonne direction et un exemple assez impressionnant de l'extensibilité de Mercurial.

L'extension watchman est interessante pour plus d'utilisateurs. Par exemples les dépots de Mozilla sont suffisamment gros pour y voir une amélioration sensible.

Il y a deux obstacles principaux au portage de Mercurial vers python3.

Le premier est lié au changement (str, unicode) → (bytes, str). Mercurial manipule principalement des bytes (le contenu d'un fichier sont des bytes, les noms de fichiers sont des bytes, les protocoles réseaux s'échangent des bytes). Hors les bytes dans python3 sont capable de faire moins de chose que les str de python2. Le googler qui s’intéresse au port de Mercurial vers python 3 discute avec d'autres développeur Python pour arranger ça.

Le second est un problème de performance. Python 3 est sensiblement plus lent, en particulier à démarrer (et pour l'import de module il me semble) ce qui est critique pour Mercurial qui est processus avec des temps de vie cours. Encore un fois Il me semble que des développeurs python tentent d'améliorer ça.

Aucun de ces deux problèmes ne correspond à ce pourquoi Victor c'est fâché avec Matt Mackall ;-)

J'utilise aussi rsnapshot pour mes archives personnelles. J'en suis assez content et la mise en place est très simple. Pour les systèmes pro un peu plus compliqué j'utilise backuppc.

Pourquoi diable proposer un logiciel libre qui va combler le manque de beaucoup de choses pour les utilisateurs de produits Apple.

C'est généralement des développeurs qui utilise XXX qui décide faire de boulot pour porter le logiciel XXX. C'est leurs plateformes qu'ils ont choisit (ou pas) et la magie du logiciel libre est qu'il peuvent contribuer pour se donner accès à un logiciel. qui l'intéresse. Et comme Mplayer n'est pas un projet GNU, Il y a peu de chance que les patches soit rejeté pour alliance avec le démon (FreeBSD bien sur)

Oui, il reste de truc un peu pénible dans les subrepos. Ça s'améliore petit à petit mais on est encore loin de la perfection :-/

Oui avec hgsubversion

Ce n'est toujours pas très claire. Je n'arrive pas à comprendre le problème que tu tente de soulever.

L'inspiration n'est pas vraiment unidirectionnel.

MQ est arrivé dans Mercurial avant que git-stash n'apparaissent alors que rebase est arrivé dans Mercurial après avoir introduit dans git.

Le fait que tout ceci soit une extension ne change pas grand chose. Une des philosophie de Mercurial est d'avoir un cœur simple, facile à prendre en main et de permettre au gens de rajouter des fonctionnalités plus complexe au fur et à mesure qu'il en ressent le besoin.

Pas vraiment (pour ne pas dire "pas du tout").

Ça introduit un nouveau concept (non proposé git) pour résoudre un problème (présent dans git)

(ta réponse sent un peut le troll du coup)

En général on préconise plutôt:

• Soit d'avoir deux fichier (un d'exemple suivit par le DVCS et un autre non suivit)
• Soit d'utiliser l'extension keyword pour configurer des valeurs spécifiques

--

Pour répondre strictement à ta question, tu peux maintenant committer ton fichier de configuration dans un changeset "secret" qui ne sera ni pusher ni puller.

Une suite de command simple pour faire ça serait

hg add mon-fichier.conf
hg commit --config phases.new-commit=secret

Par contre il faudra que tu t'arrange pour que les commit que tu veux pousser ne soit les descendants de ton changeset secret. Sinon il ne seront pas pousser non plus. Tu peux le faire soit en utilisant hg update "not secret()" pour revenir sur le parent de ton commit secret avant de commiter toi en utilisant hg rebase après coup.

D'ailleurs si le client avait pullé entre temps, tu peux être sûr que tu ne lui aurai jamais retiré le commit problématique sans son accord...
Et les phases Mercurial ne feront rien contre.

Justement l'idée des phases Mercurial est de garder une trace des changesets qui existent à des endroits où il te sera difficile les supprimer.

Les versions précédentes de Mercurial se plaignait déjà au moment du push (dans la même veine de ce que fait git). La nouveauté apportée par les phases, c'est le fait de prévenir ces problèmes le plus tôt possible en refusant des le départ de récrire les partis d'historique dont on sait que leur réécriture posera problème.

En quelque sorte c'est un équivalent du mantra: "Tu ne réécrira pas " qui prévaux dans git. Mais garanti directement par l'outil. Ça facilite la vie des gens qui ont une compréhension limité des DVCS (et la vie des gens qui les encadrent…)

Pour finir on notera que les utilisateurs avancés pourront toujours contrôler finement la manière dont Mercurial va marquer la section de l'historique immuable. Ce n'est pas parce que les choses prévue pour être simple et sûre pour les humains normaux que les autres devrait se limiter

Le suivi d'un dépôt par un autre dépôt existe dans mercurial depuis 2 ans. Mais sous un autre nom: http://mercurial.selenic.com/wiki/Subrepository

Dans le même genre et à ne pas louper: la variable CDPATH. Elle se comporte comme la très classique variable PATH mais pour les changements de répertoire. Lorsque vous faite cd jungle/babar et qu'il n'y a de répertoire jungle/babar dans votre répertoire courant votre shell cherche parmi les éléments de CDPATH ?

Il n'y a plus qu'à attendre que developpez.com fasse fermer linuxfr.