D'ailleurs, j'ai pas vraiment trouvé de réponse sur le net, est-il possible d'avoir un index comme dans git ? (obligeant de sélectionner ce qu'on commit) voir même en utilisant un plugin hein.
On peut évidemment choisir lors du commit, mais j'aime bien le fonctionnement inverse
A part l'extension record, qui permet de choisir au commit ce qu'on veut mettre, il n'y a pas de truc "persistant" qui permettrait de dire "ça c'est pour le prochain commit". C'est pas un truc dur à faire, je pense que personne n'a trop eu le besoin (et la plupart des gens aiment pas trop comme approche, vu que ça fait committer des trucs pas testé).
Sinon y'a mq qui permet de faire ça et plein d'autres choses (principalement faire des séries de patchs propres), mais c'est pour les utilisateurs avancés.
Au fait, pourquoi être dev hg (si c'est pour le "plaisir") et pas sur un autre ? (en gros pourquoi l'avoir choisit ?)
Oui, c'est pour le plaisir.
D'abord, en 2005 quand git et hg ont été crée, hg était vraiment devant (git avait pas de repack et donc les repos prenaient quelques gigas, pas d'interface utilisateur, etc.), et c'est le moment où j'ai commencé à contribuer.
Git avait pas grand chose pour lui, sauf le fait d'être crée par Linus, mais bon hg était pas en reste, Matt étant une personne très intelligente (et également respecté dans la communauté du kernel).
Ensuite c'est en python, et donc, à mon avis, plus agréable. Y'a pas besoin de 50 lignes de code pour les trucs simples de l'interface utilisateur (qui ont pas besoin d'être rapide), ou pour les accès réseaux. En général le code est plus homogène: git s'est amélioré depuis, mais entre du C+python, et du C+sh+perl, j'avais trouvé mon camp ;)
Enfin bzr c'était juste un truc très très lent à l'époque, avec du python over-engineeré (du xml, etc.), donc j'ai jamais sérieusement considéré. D'ailleurs canonical a failli abandonné bzr pour hg à un moment tellement ils avaient du mal, ça n'a pas eu lieu pour des problèmes de licence (ils voulaient le pouvoir sur le copyright, pour launchpad qui était pas libre).
Et aussi, la communauté de mercurial est super sympa, les gens sont aimables sur irc et la mailing list, ça compte aussi quand on contribue à un projet.
[^] # Re: Mercurial
Posté par ribwund . En réponse au journal des migrations de systèmes de sources. Évalué à 2.
On peut évidemment choisir lors du commit, mais j'aime bien le fonctionnement inverse
A part l'extension record, qui permet de choisir au commit ce qu'on veut mettre, il n'y a pas de truc "persistant" qui permettrait de dire "ça c'est pour le prochain commit". C'est pas un truc dur à faire, je pense que personne n'a trop eu le besoin (et la plupart des gens aiment pas trop comme approche, vu que ça fait committer des trucs pas testé).
Sinon y'a mq qui permet de faire ça et plein d'autres choses (principalement faire des séries de patchs propres), mais c'est pour les utilisateurs avancés.
Au fait, pourquoi être dev hg (si c'est pour le "plaisir") et pas sur un autre ? (en gros pourquoi l'avoir choisit ?)
Oui, c'est pour le plaisir.
D'abord, en 2005 quand git et hg ont été crée, hg était vraiment devant (git avait pas de repack et donc les repos prenaient quelques gigas, pas d'interface utilisateur, etc.), et c'est le moment où j'ai commencé à contribuer.
Git avait pas grand chose pour lui, sauf le fait d'être crée par Linus, mais bon hg était pas en reste, Matt étant une personne très intelligente (et également respecté dans la communauté du kernel).
Ensuite c'est en python, et donc, à mon avis, plus agréable. Y'a pas besoin de 50 lignes de code pour les trucs simples de l'interface utilisateur (qui ont pas besoin d'être rapide), ou pour les accès réseaux. En général le code est plus homogène: git s'est amélioré depuis, mais entre du C+python, et du C+sh+perl, j'avais trouvé mon camp ;)
Enfin bzr c'était juste un truc très très lent à l'époque, avec du python over-engineeré (du xml, etc.), donc j'ai jamais sérieusement considéré. D'ailleurs canonical a failli abandonné bzr pour hg à un moment tellement ils avaient du mal, ça n'a pas eu lieu pour des problèmes de licence (ils voulaient le pouvoir sur le copyright, pour launchpad qui était pas libre).
Et aussi, la communauté de mercurial est super sympa, les gens sont aimables sur irc et la mailing list, ça compte aussi quand on contribue à un projet.