Mercurial fait partie des VCS (Logiciel de gestion de versions) libres reconnus à côté entre autres de Subversion et de Git dont il est assez proche. Le projet est sponsorisé majoritairement par les sociétés ou organisations suivantes : Google, Fog Creek (Stack Overflow), Microsoft, Jane Street Capital, Allston Trading, Mozilla, Symbian, Python, Atlassian.
La version 1.7 de mercurial est sortie le 1er novembre 2010. La majorité des changements est détaillée dans la suite de la dépêche. Les projets suivants utilisent mercurial (liste arbitraire) : Adium, Bitbucket, Dillo, Dovecot, Gajim, LibSDL, Mozilla, mutt, NetBeans, OpenJDK, OpenOffice, OpenSolaris, Python, SAGE, Symbian Platform, TortoiseHg, Vim, Wget, wmii, Xen, Xine.
On peut noter la présence de plusieurs projets bien plus anciens que 2005 et qui ont donc fait le choix de mercurial lorsqu'ils ont voulu améliorer l'efficacité de la gestion de leurs sources.
Pour ce qui est de ses outils, mercurial n'a rien à envier à ses concurrents. L'outil officiel en ligne de commande 'hg' est très abouti et agréable à utiliser.
Tortoisehg permet une intégration complète de mercurial de manière graphique dans Microsoft Windows en tant qu'extension shell. Il a été porté sur Gnome/Nautilus, est utilisable via pygtk, et est en cours de portage vers Mac OS X.
Le greffon Eclipse HGE permet l'intégration de mercurial dans l'IDE Eclipse alors que l'IDE Netbean prend en charge nativement mercurial.
Bien d'autres encore sont listés sur le wiki mercurial (oui oui ça peut aussi s'intégrer dans vim/emacs).
Quelques sites permettant l'hébergement gratuit de projets libres avec mercurial :
- Bitbucket http://www.bitbucket.org (racheté par Atlassian le 29 septembre 2010).
- CodePlex http://www.codeplex.com (Microsoft. Un article sur le sujet ).
- Google Code http://code.google.com/projecthosting/ .
- Intuxication - http://mercurial.intuxication.org .
- Sharesource - http://sharesource.org .
- SourceForge - http://sourceforge.net .
- Codingteam [17] - http://codingteam.net
- TuxFamily.org[18] - http://tuxfamily.org.
Du 8 au 10 octobre a eu lieu un long week-end de '1.7 Sprint' regroupant pas moins de 13 développeurs (dont 6 européens et 1 australien) dans les locaux de Google Chicago [14][15][16]. Au-delà du travail accompli sur la version 1.7, ce fut l'occasion pour les participants de partager leurs réflexions sur l'avenir de mercurial et les prochaines évolutions majeures.
Changelog de la version 1.7 (traduit partiellement) :
1/ Cœur
- Évolution du format des dépôts 'dotencode' : amélioration de la gestion des noms des fichiers qui contiennent des espaces et des points.
Également ajouté : une option expérimentale 'parentdelta' lors de la création d'un dépôt qui améliore l'efficacité de la compression des dépôts comprenant des branches dans leur historique. Voir [5] pour plus d'informations.
2/ Commandes
- Ajout de la possibilité d'utiliser des commandes shell dans les alias.
- Backout (Retour en arrière sur un lot de changement) : ajout de l'argument '--tool' pour spécifier l'outil de merge utilisé et choix du mode linéaire par défaut.
- Merge : Ajout de l'argument '--tool' afin de spécifier directement l'outil que l'on souhaite utiliser.
- templater : nouveau filtre 'hex' et mot clef 'children' pour les templates d'affichage.
3/ Sous-dépôts
Note : les sous-dépôts [6] sont une fonctionnalité qui permet de gérer un ensemble de dépôt comme un groupe. Le support de cette fonctionnalité est étendue à de plus en plus de commandes au fil des versions de mercurial.- Ajout de la possibilité de faire de la réécriture d'url sur les chemins des sous dépôts.
- Ajout de la récursion dans les sous-dépôts pour les commandes add, diff, incoming, outgoing et status.
- Ajout du support de la commande archive.
4/ Revsets
Note : Revsets est le nom donné au langage fonctionnel permettant de spécifier un ensemble de révision. Voir « hg help revsets ».- Ajout des opérateurs id et rev pour permettre des références explicites aux changements.
- Ajout de la fonction min pour sélectionner le lot de changement avec le plus petit identificateur de révision.
- Ajout de la fonction present pour éviter les erreurs de recherche.
- Renommage de la fonction tagged en tag.
- Ajout du support des revsets dans les commandes suivantes : strip, bisect, update.
- bookmarks : ajout d'un revset bookmark pour référencer les bookmarks.
- transplant : ajout d'un revset transplant pour avoir les révisions provenant d'un transplant.
5/ hgweb
- Ajout d'un lien vers la documentation intégrée.
- Le mode HTTPS utilise maintenant une méthode de chiffrement permettant plus de compatibilité mais moins sécurisée.
- Ajout d'un champ ETag dans les en-têtes HTTP pour améliorer la gestion du cache des pages.
6/ Extensions
- color : meilleur support des branches et des mq guards.
- convert : corrections de bugs, dépréciation de --authors pour --authormap.
- graphlog : support des templates header/footer dans les styles.
- keyword : support des commandes copy et rename. Ne s'étend plus durant les diff.
- mq : extension du support de l'argument --mq pour les extensions de commande.
- mq/qqueue : gestion du renommage des files d'attentes actives. Ajout de l'option --purge pour effacer une file et ses patchs.
- pager : ajout de l'option globale --pager=.
- patchbomb : ajout de l'option --confirm. diffstat n'affiche plus qu'une seule fois le résumé complet.
- progress : support de rebase et patchbomb.
- strip : ajout de l'option --keep pour éviter de modifier la copie de travail. Renommage de l'option --nobackup en --no-backup. Supporte maintenant plusieurs révisions.
7/ contrib
- Ajout de vimdiff dans le script mergetools (script d'amélioration de la configuration pour certains outils de merge).
- Amélioration de la complétion zsh
Et également diverses corrections de bogues, ajout et amélioration de performance.
Références :
1. http://mercurial.selenic.com/wiki/WhatsNew#A1.7_.282010-11-0(...)2. http://fr.wikipedia.org/wiki/Mercurial
3. http://stackoverflow.com/about/management
4. http://hg-scm.org/sponsors/
5. http://mercurial.selenic.com/wiki/UpgradeNotes
6. http://mercurial.selenic.com/wiki/Subrepository
7. http://www.consortiuminfo.org/standardsblog/article.php?stor(...)
8. http://blog.bitbucket.org/2010/09/29/bitbucket-joins-atlassi(...)
9. http://tortoisehg.bitbucket.org/
10. http://tortoisehg.bitbucket.org/
11. http://javaforge.com/project/HGE
12. http://netbeans.org/features/ide/collaboration.html
13. http://mercurial.selenic.com/wiki/OtherTools
14. http://mercurial.selenic.com/wiki/1.7sprint
15. http://blog.bitbucket.org/2010/10/09/mercurial-1-7-sprint-in(...)
16. http://www.selenic.com/blog/?p=681
17. http://linuxfr.org/2010/06/17/27003.html
18. Mercurial chez TuxFamily.org
# Sismotherapie
Posté par Frank-N-Furter . Évalué à 5.
La rééducation est à base d’électrochocs?
Depending on the time of day, the French go either way.
[^] # Re: Sismotherapie
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
- Comment se comporte Mercurial avec les fichiers binaires ?
- Au niveau de la gestion des droits du dépôt central, ça marche a peu près comme SVN ?
Oui, je sais, c'est un gestionnaire dé-centralisé mais si on veut une référence, comment se passe la gestion des droits ?
[^] # Re: Sismotherapie
Posté par ymorin . Évalué à 4.
Deux possibilités:
- 'nativement' : les fichiers binaires sont détectés, et stockés 'comme ca'.
- avec une extension (bfiles),
J'ai pas essayé bfiles. Par contre, j'ai un fichier binaire conséquent (et qui évolue peu) dans mon repository, et Mercurial se démerde plutôt OK.
> Au niveau de la gestion des droits du dépôt central, ça marche a peu près comme SVN ?
Plusieurs solutions aussi :
- authentification par le serveur http/https, si tu veux pousser par http/https
- authentification par ssh, si tu veux pouser par ssh
Pour ma part, http/https sont en lecture seule, et je pousse uniquement par ssh.
[^] # Re: Sismotherapie
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
- via la configuration du serveur apache -> identification de la personne sur le serveur
- via le fichier svnaccess -> autorisation de la personne pour un projet donné
Les deux choses sont bien séparé et en pratique, c'est plutôt bien et facile à maintenir.
J'avais éliminé le ssh pour ne pas avoir à gérer la problématique de l'accès physique au serveur.
[^] # Re: Sismotherapie
Posté par Stéphane Klein (site web personnel) . Évalué à 2.
* ssh
* http
Regarde par exemple les choix possibles sur bitbucket, tu comprendras.
Pour information, il y a une application web nommée "RhodeCode" ( http://packages.python.org/RhodeCode/index.html ) qui permet créer / administrer un centre de dépôts avec gestion des utilisateurs / droits / dépôts privés / création / suppression… c'est pas mal. Dans ce projet, l'authentification se fait uniquement par http (pas de ssh).
# Très interessant
Posté par rpointel . Évalué à 2.
Je commence à me documenter un peu dessus car c'est ce que je souhaiterais utiliser chez moi pour mon dev, cette actualité tombe au meilleur moment.
[^] # Re: Très interessant
Posté par bluelambda . Évalué à -7.
C'est à peu près pareil que Mercurial, sauf que ça marche. Bon ok je troll un peu :D
J'utilise les deux au boulot, et pour moi ya pas photo :) je trouve Git plus agréable et plus fiable que HG.
Donc je te conseille de comparer les deux avant d'en choisir un.
[^] # Re: Très interessant
Posté par rpointel . Évalué à 1.
[^] # Re: Très interessant
Posté par Stéphane Klein (site web personnel) . Évalué à 0.
Chez Mercurial marche très très bien.
Idem pour Bazaar.
[^] # Re: Très interessant
Posté par Stéphane Klein (site web personnel) . Évalué à 0.
[^] # Re: Très interessant
Posté par ymorin . Évalué à 7.
> C'est à peu près pareil que Mercurial, sauf que ça marche.
De mon expérience, les différences entre Git et Mercurial, d'un point de vue pratique, sont :
- pour un contributeur occasionel : la CLI de Hg est plus rapide à maitriser
- pour un contributeur régulier : la CLI de Hg est plus simple à utiliser
- pour le mainteneur : la paradigme Hg est plus rapide a comprendre, et maintenir le projet est plus simple.
Alors bien sûr, ce n'est qu'un retour de mon expérience personelle à moi. YMMV, comme ils disent.
Enfin, tout de même un trés gros bonus pour Mercurial : les MQ. Avec les MQ, le développeur maintient une serie de patchs par dessus le repository, et se ballade facilement avec des empilements/depilements (qpush/qpop). C'est très utile lorsqu'une modification est découpée en plusieurs étapes : ca permet de tester un ensemble de changements de revenir en arrière, de recommencer, etc... sans avoir fait le moindre commit.
Alors bien sur, on peut aussi faire ça avec Git, mais c'est plus compliqué. Il y a bien un utilitaire, stgit, mais il semble n'être plus maintenu, et n'est pas intégré 'de base' à Git, quand les MQ sont natives dans Mercurial.
[^] # Re: Très interessant
Posté par GeneralZod . Évalué à 3.
[^] # Question MQ
Posté par komuta . Évalué à 2.
[^] # Re: Question MQ
Posté par Antoine . Évalué à 2.
(après, il se peut qu'il y ait des bugs)
Ceci dit, il y aussi une extension "rebase" qui permet de faire la même chose que git rebase, sans l'aide de MQ.
[^] # Re: Question MQ
Posté par ymorin . Évalué à 3.
Pardon, pardon, mais c'est (en partie du moins) possible :
---8<---
# LC_ALL=fr_FR.UTF8 hg help qimport
[...]
Un "changeset" existant peut-être placé sous le contrôle de mq à l'aide de -r/--rev (par
exemple qimport --rev tip -n patch placera la révision tip sous le contrôle de mq).
[...]
---8<---
Mais MQ travaillant sur une série de patches, je comprend qu'il ne soit pas possible de transformer un embranchement de l'arbre (merge ou branche) en patch. Il n'est pas possible de stocker dans un patch ce genre d'info.
[^] # Re: Question MQ
Posté par GeneralZod . Évalué à 3.
git rebase -i ne peut modifier l'historique que d'une seule branche, si tu touches à un commit partagés par plusieurs branches, ça revient à changer le parent de ta branche et à créer un nouveau commit en cas de modification. C'est toujours possible avec à l'aide de plusieurs files (hg help qqueue) ou des extensions rebase et transplant mais dans ce cas-là, c'est plus fastidieux qu'avec git.
En même temps, ça reste cohérent avec la philosophie de mercurial qui déconseille l'édition de l'historique, comme on it: "there's no such thing as one size fits all".
Quant à histedit, j'ai peu utilisé donc je ne peux pas dire grand chose à ce sujet.
[^] # Re: Très interessant
Posté par Sébastien Douche . Évalué à 3.
> empilements/depilements (qpush/qpop). C'est très utile lorsqu'une modification est découpée
> en plusieurs étapes : ca permet de tester un ensemble de changements de revenir en arrière,
> de recommencer, etc... sans avoir fait le moindre commit.
J'ai utilisé Hg pendant 2 ans au taff (maintenant c'est git) , ou on employé tous MQ massivement (on a du produire des centaines de patchs) donc je connais assez bien. MQ n'existe pas dans git... car c'est totalement inutile. La gestion des branches est tellement plus avancée que cette fonctionnalité n'est pas utile.
De plus, MQ est utile quand on est seul, mais devient intenable pour du travail collaboratif.
Note: MQ est une copie de Quilt, l'outil utilisé par... Linus torvalds avant de passer à BitKeeper. Il est donc parfaitement conscient de ce type d'outil et ce n'est pas un hasard si cela n'existe pas.
[^] # Re: Très interessant
Posté par GeneralZod . Évalué à 4.
Tellement inutile qu'on a recréé des surcouches de Git pour gérer les patchs: stGit, Guilt (qui s'inspire directement des MQ) et bien d'autres.
> La gestion des branches est tellement plus avancée que cette fonctionnalité n'est pas utile.
Tu parles des branches légères ? hg help heads (si tu veux les nommer comme dans Git ==> extension standard bookmarks). Pour le reste, ça se vaut.
Néanmoins, même si les branches légères permettent partiellement de pallier à l'absence d'un outil de gestion de patchs, ça ne les remplacent pas complétement.
> De plus, MQ est utile quand on est seul, mais devient intenable pour du travail collaboratif.
MQ permet de versionner le dépôt de patchs (hg init --mq) pour permet de travailler en mode collaboratif.
> Note: MQ est une copie de Quilt, l'outil utilisé par... Linus torvalds avant de passer à BitKeeper
Linus a commencé à utiliser bitkeeper en 2002, quilt remonte à 2003 (les scripts d'Andrew Morton ont été publiés qui ont servi de base à quilt ont été publié en 2002). Chronologiquement, ça ne colle pas ton histoire.
De plus, MQ c'est un quilt survitaminée et très bien intégré à hg, ça permet de réaliser des opérations avancés qui vont bien au-delà de la simple gestion de patchs comme la réécriture de l'historique (et ce bien mieux que Git !). Les extensions de Mercurial permettent d'offrir un noyau simple à appréhender sans pour autant brider les utilisateurs avancés qui activent uniquement ce dont ils ont besoin.
> Il est donc parfaitement conscient de ce type d'outil et ce n'est pas un hasard si cela n'existe pas.
La demande d'un outil de gestion des patchs intégré à Git revient régulièrement dans les Git Surveys, donc ça contredit ton affirmation "Nan, on n'a pas besoin de ça".
[^] # Re: Très interessant
Posté par Victor . Évalué à 5.
Vous voulez faire des trucs patch-oriented ? Tournez-vous vers darcs !
[^] # Re: Très interessant
Posté par Sébastien Douche . Évalué à 2.
[^] # Re: Très interessant
Posté par Sébastien Douche . Évalué à 0.
> Tellement inutile qu'on a recréé des surcouches de Git pour gérer les patchs: stGit, Guilt
> (qui s'inspire directement des MQ) et bien d'autres.
Qui "on" ? Pas les développeurs de Git.
> La gestion des branches est tellement plus avancée que cette fonctionnalité n'est pas utile.
>> Tu parles des branches légères ?
Je ne vois pas que c'est une "branche légère" dans Git. Ca c'est une formulation Hg.
>> Note: MQ est une copie de Quilt, l'outil utilisé par... Linus torvalds avant de passer à BitKeeper
> Linus a commencé à utiliser bitkeeper en 2002, quilt remonte à 2003 (les scripts d'Andrew
> Morton ont été publiés qui ont servi de base à quilt ont été publié en 2002).
> Chronologiquement, ça ne colle pas ton histoire.
Quilt n'est qu'une évolution des scripts utilisés par les développeurs du noyau (avant BitKeeper, ils avaient bien un outil et ce n'était pas CVS).
> La demande d'un outil de gestion des patchs intégré à Git revient régulièrement dans les
> Git Surveys, donc ça contredit ton affirmation "Nan, on n'a pas besoin de ça".
Les gens demandent aussi des poneys roses.
Perso j'arrête la la discussion, le prosélytisme aveugle, ca me gonfle rapidement. Hg a des avantages intéressants sur Git, mais surement pas dans la capacité de gérer un DAG ou de revoir un historique. Mais pour cela, il faut connaitre les 2 outils.
[^] # Re: Très interessant
Posté par Albert_ . Évalué à 2.
[^] # Re: Très interessant
Posté par GeneralZod . Évalué à 2.
Pour info, mon Git-fu est aussi bon que mon hg do.
[^] # Re: Très interessant
Posté par sifu . Évalué à 1.
Merci.
[^] # Re: Très interessant
Posté par GeneralZod . Évalué à 3.
Shawn Pearce (2ème commiter dans Git devant Linus) avait écrit un quilt-like (abandonné depuis) et récemment Petr Baudis (TopGit). StGit et Guilt sont maintenus par des contributeurs de moindre importance.
> Je ne vois pas que c'est une "branche légère" dans Git. Ca c'est une formulation Hg.
Même pas, on parle de heads dans le jargon mercurial, les branches "légères" est un terme générique pour désigner les branches au sein d'un même clone, les branches "lourdes" désignant eux les clones.
> Quilt n'est qu'une évolution des scripts utilisés par les développeurs du noyau (avant BitKeeper, ils avaient bien un outil et ce n'était pas CVS).
Andrew Morton a publié ces scripts en 2002 - à l'époque où Linus a décidé d'utiliser BitKeeper - et c'était très rudimentaire.
http://lwn.net/Articles/13518/
> Les gens demandent aussi des poneys roses.
Si deux développeurs majeurs de Git ont proposés des surcouches pour gérer cette fonctionnalités, c'est peut-être pas si stupide que ça.
> Perso j'arrête la la discussion, le prosélytisme aveugle, ca me gonfle rapidement
>> La gestion des branches est tellement plus avancée que cette fonctionnalité n'est pas utile.
>> De plus, MQ est utile quand on est seul, mais devient intenable pour du travail collaboratif.
C'est très bien de reconnaitre ses erreurs.
> Mais pour cela, il faut connaitre les 2 outils.
Je plusse.
[^] # Re: Très interessant
Posté par Troy McClure (site web personnel) . Évalué à 5.
[^] # Re: Très interessant
Posté par GeneralZod . Évalué à 3.
[^] # Re: Très interessant
Posté par Albert_ . Évalué à 1.
Ancien utilisateur de SVN utilisait hg
Neophyte faites vos tests mais je soupconne que pour une utilisation "premier abord" les deux se valent.
Perso je prefere git (il ne se traine pas la passif de svn et donc de cvs...).
[^] # Re: Très interessant
Posté par GeneralZod . Évalué à 3.
Rien que le fait de pouvoir travailler hors-ligne (et par conséquent de meilleures performances), la gestion des branches, et un merge fonctionnel, on peut oublier les antiquités tels que CVS ou même SVN.
> Perso je prefere git (il ne se traine pas la passif de svn et donc de cvs...).
idem pour mercurial ...
[^] # Re: Très interessant
Posté par djano . Évalué à 3.
J'ai failli te plusser, mais quand j'ai lu cette phrase que j'interprète comme "git ne se traîne pas le passif de SVN, alors que hg se le traine", et bien j'ai eu très envie de t'inutiler car c'est complétement faux. J'ai réussit a résister malgré tout.
Hg, tout comme Git, est basé sur des concepts totalement différents de CVS et SVN et ne se traîne aucun passif.
Par ailleurs, SVN ne traîne aucun passif de CVS. Ils ont juste choisit de faire un VCS centralisé (comme CVS), mais ils ont fait table rase de tout le reste et n'hésitent pas a remettre en cause des choix faits dans les versions précédentes de SVN. Maintenant le modèle centralise ne correspond peut être pas a ton workflow ou a celui du libre, mais ca correspond encore a celui de beaucoup de personnes.
[^] # Re: Très interessant
Posté par aedrin . Évalué à 4.
Je le trouve plus clair que le hg book, il introduit assez bien les notions.
[^] # Re: Très interessant
Posté par Yth (Mastodon) . Évalué à 2.
Yth.
# Extension maison
Posté par Sébastien Douche . Évalué à 3.
[^] # Re: Extension maison
Posté par Vincent . Évalué à 2.
Il y a un exemple d'utilisation ici: http://amp.carboni.ca/docs/
C'est vraiment un gros plus pour faire de l'intégration comme brique d'un projet.
[^] # Re: Extension maison
Posté par Victor STINNER (site web personnel) . Évalué à 1.
Il me semble que c'est plutôt Ruby qui est utilisé pour scripter Ruby. Sinon on dirait qu'on peut scripter Git dans pas mal de langages :
https://git.wiki.kernel.org/index.php/Interfaces,_frontends,(...)
Est-ce qu'il n'existe pas une bibliothèque C pour git ? libgit2 semble être un bon candidat : « Pure C reimplementation of the core Git data structures and repository access. »
http://repo.or.cz/w/libgit2.git
[^] # Re: Extension maison
Posté par Victor STINNER (site web personnel) . Évalué à 1.
Il fallait lire : pour scripter Git ...
PS : Cette BD de nojhan est plutôt énervante par moment.
# Sites d'hébergement mercurial : lesquels sont libres ?
Posté par gasche . Évalué à 3.
Côté git, j'utilise gitorious plutôt que github pour cette raison. J'ai regardé rapidement BitBucket, et je n'ai vu nulle part d'indication sur un éventuel code source disponible (donc j'imagine que ce n'est pas libre).
Ce n'est pas du tout basé sur des raisons pragmatiques (en local j'utilise de simple repos darcs/git/whatever, la plus value de l'hébergement en ligne c'est l'accès facile en lecture par tout le monde), mais je trouve absurde de dépendre d'un logiciel propriétaire pour diffuser ses projets libres...
[^] # Re: Sites d'hébergement mercurial : lesquels sont libres ?
Posté par Vincent . Évalué à 3.
http://codingteam.org
[^] # Re: Sites d'hébergement mercurial : lesquels sont libres ?
Posté par BAud (site web personnel) . Évalué à 3.
# Directory rename et merge
Posté par djano . Évalué à 2.
- Dans trunk (ou main), j'ai un répertoire "dir"
- Je crée la branche A a partir de trunk
- Dans trunk, je renomme le répertoire "dir" en "rep"
- Dans la branche A, j'ajoute un fichier "file" au répertoire "dir". Le numéro de révision est 10378.
- Quand je merge la révision 10378 de la branche A vers trunk, voici ce que je veux obtenir: le fichier "file" est ajouté au répertoire "rep" de trunk.
Aucun des VCS que j'ai testé ne permet ca automatiquement:
- SVN refuse cela et me repond "tree conflict"
- Git l'accepte, mais me crée un fichier "file" dans le répertoire "dir" sur trunk (alors que je voulais ce fichier dans le répertoire "rep")
- D'après ce que j'ai lu sur Mercurial, qui ne se rappelle pas des répertoires, je ne pense pas que ca marcherait. Mais je ne sais pas ce que ca fait.
- Avez vous d'autres idées d'outils?
[^] # Re: Directory rename et merge
Posté par El Titi . Évalué à 2.
Désolé :O)
[^] # Re: Directory rename et merge
Posté par djano . Évalué à 2.
Ici, je parle seulement d'utiliser des gestionnaires de code source qui n'ont pas besoin d'un bataillon d'administrateurs pour les gérer.
[^] # Re: Directory rename et merge
Posté par El Titi . Évalué à 3.
Je viens de tester.
[^] # Re: Directory rename et merge
Posté par El Titi . Évalué à 3.
Since Mercurial's rename is implemented as copy-and-remove, the same propagation of changes happens when you merge after a rename as after a copy.
If I modify a file, and you rename it to a new name, and then we merge our respective changes, my modifications to the file under its original name will be propagated into the file under its new name. (This is something you might expect to "simply work", but not all revision control systems actually do this.)
Whereas having changes follow a copy is a feature where you can perhaps nod and say "yes, that might be useful," it should be clear that having them follow a rename is definitely important. Without this facility, it would simply be too easy for changes to become orphaned when files are renamed.
http://hgbook.red-bean.com/read/mercurial-in-daily-use.html
Ceci s'applique aussi aux répertoires.
En revanche, j'ignorais que git ne savait pas le gérer correctement.
[^] # Re: Directory rename et merge
Posté par djano . Évalué à 3.
En revanche, j'ignorais que git ne savait pas le gérer correctement.
Je te raconte pas la déception par rapport aux fameuses heuristiques tant vantées par Linus Torvalds. J'avais vraiment envie de dire bullshit!
M'enfin j'avais teste avec msysGit (ou un truc dans le genre) sous Windows, alors peut être que ca a été corrige depuis, mais ca a été tellement la galère pour l'installer. Ajout d'un patch pour le faire marcher etc.
[^] # Re: Directory rename et merge
Posté par El Titi . Évalué à 2.
Mais si ce que tu affirmes est vrai, le choix sera vite fait.
[^] # Re: Directory rename et merge
Posté par djano . Évalué à 2.
Je décline toute responsabilité quand a l'interprétation de mes résultats car ca remonte a quelques temps, et je pourrais avoir loupé un détail important. Moralité, fait ton propre test, et n'hésite surtout pas a me donner tes conclusions.
[^] # Re: Directory rename et merge
Posté par El Titi . Évalué à 2.
[^] # Re: Directory rename et merge
Posté par djano . Évalué à 2.
[^] # Re: Directory rename et merge
Posté par CrEv (site web personnel) . Évalué à 3.
non, j'ai fait le test avec un git 1.7.3 et le workflow du dessus (renomer dir en rep dans le tronc puis merge après ajout d'un fichier au répertoire dans une autre branche) ne fonctionne pas avec git.
Rien que pour ce point git tombe pas mal par rapport à mercurial (même s'il faut avouer que c'est pas non plus un cas hyper fréquent).
Entre ça, l'intégration dans eclipse, dans windows mercurial va devenir mon choix de scm, du moment qu'on comprend comment mercurial gère les heads (sans ça c'est compliquer mercurial...)
[^] # Re: Directory rename et merge
Posté par El Titi . Évalué à 2.
Il me semble que le développement est très actif en ce moment et que ca évolue vite.
[^] # Re: Directory rename et merge
Posté par djano . Évalué à 2.
J'avais cru voir que la fondation Eclipse passait a Git, et donc le travail sur EGit est très prioritaire pour eux.
[^] # Re: Directory rename et merge
Posté par djano . Évalué à 2.
Pour nous c'en est un: passage d'une base de code monolithique a des sous projets avec déplacement de répertoire a la clé. Et c'est même plutôt chiant quand les vieilles branches vivent des lustres. C'est increvable ces trucs la!
[^] # Re: Directory rename et merge
Posté par djano . Évalué à 2.
Il ne me reste plus qu'a trouver comment lier Mercurial a svn comme Git sait le faire.
[^] # Re: Directory rename et merge
Posté par El Titi . Évalué à 1.
http://mercurial.selenic.com/wiki/WorkingWithSubversion
Il y plusieurs solutions mais aucune aussi satisfaisante que git-svn d'après ce que j'ai lu.
Mais je n'ai pas testé
[^] # Re: Directory rename et merge
Posté par djano . Évalué à 2.
[^] # Re: Directory rename et merge
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
Bonne nouvelle : il y a une série de patchs en préparation pour ajouter ça :
* yd/dir-rename (2010-10-29) 5 commits
- Allow hiding renames of individual files involved in a directory rename.
- Unified diff output format for bulk moves.
- Add testcases for the --detect-bulk-moves diffcore flag.
- Raw diff output format for bulk moves.
- Introduce bulk-move detection in diffcore.
[^] # Re: Directory rename et merge
Posté par El Titi . Évalué à 3.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.