Mercurial, c'est tout aussi puissant et ça peut s'utiliser via une interface graphique (HgWorkbench).
Sous windows, il doit bien y avoir tortoiseGit, me semble?
Après comme on a une réputation a tenir, on active la console en bas de l'interface histoire qu'il y ait plein de commandes qui défilent.
Si c'est ça la raison qui te fait utiliser la ligne de commande, j'espère que tu as au moins mis un thème "matrix-like", en vert sur noir.
je ne vois pas ce qu'il a de mieux
Ne connaissant pas mercurial, ni dart, ni bazaar, et très, très peu fossil, je ne peux répondre sur «l'aspect métier» (je n'ai vraiment utilisé que SVN, et encore, en étant seul sur le projet, un peu de fossil et git).
Le seul truc que je peux dire en gros c'est:
Sur le plan technique à minima (et sur ma debian), git dépend grosso merdo de C et de perl, le paquet lui-même pèse 36.2M. Mercurial, lui, pèse lui-même 923K+13.2M (~14M) et dépend de python, à vue de nez, l'installation totale me consommerait donc ~30.8M, un peu moins que git.
Pour être franc, ça me surprend énormément, ça a du changer à un moment (git aurait pris de l'embonpoint peut-être? Je vois une chiée de binaire qui sont probablement peu utilisés dans l'archive... bref), parce que c'est l'un des trucs auxquels je fait attention quand je choisis un outil.
Toujours sur le registre technologique, mercurial est implémenté dans un langage qui n'est lié à aucun standard. À l'heure actuelle, la version proposée dans les dépôts stables de Debian dépends de python2. Qui n'est plus maintenu et est considéré obsolète depuis combien de temps, déjà? (je sais, ce sont 2 dates différentes).
En gros: git est codé en C, mercurial en python. J'ai personnellement un fort biais envers les langages qui ont un vrai standard, et plusieurs implémentations dont aucune n'est "l'implémentation de référence".
Ça se discute probablement, mais vu que j'aime l'idée de pouvoir utiliser un logiciel 20 après avec les correctifs et améliorations apportées depuis, ben le fait d'être codé en python est déjà un désavantage monstre.
Maintenant, je veux bien croire qu'il puisse être supérieur à git, reste à savoir en quoi ça impacte l'utilisateur final?
Dans le cas, par exemple, de fossil, l'avantage sur git est clair: c'est une forge, pas un simple DVCS. De plus, c'est facile et robuste à migrer: un seul fichier à déplacer.
Dans le cas de mercurial? Je n'ai jamais vu d'arguments qui me semblent si importants.
[^] # Re: [HS] Mercurial
Posté par freem . En réponse au message git et merge graphique. Évalué à 3.
Sous windows, il doit bien y avoir tortoiseGit, me semble?
Si c'est ça la raison qui te fait utiliser la ligne de commande, j'espère que tu as au moins mis un thème "matrix-like", en vert sur noir.
Ne connaissant pas mercurial, ni dart, ni bazaar, et très, très peu fossil, je ne peux répondre sur «l'aspect métier» (je n'ai vraiment utilisé que SVN, et encore, en étant seul sur le projet, un peu de fossil et git).
Le seul truc que je peux dire en gros c'est:
Sur le plan technique à minima (et sur ma debian), git dépend grosso merdo de C et de perl, le paquet lui-même pèse 36.2M. Mercurial, lui, pèse lui-même 923K+13.2M (~14M) et dépend de python, à vue de nez, l'installation totale me consommerait donc ~30.8M, un peu moins que git.
Pour être franc, ça me surprend énormément, ça a du changer à un moment (git aurait pris de l'embonpoint peut-être? Je vois une chiée de binaire qui sont probablement peu utilisés dans l'archive... bref), parce que c'est l'un des trucs auxquels je fait attention quand je choisis un outil.
Toujours sur le registre technologique, mercurial est implémenté dans un langage qui n'est lié à aucun standard. À l'heure actuelle, la version proposée dans les dépôts stables de Debian dépends de python2. Qui n'est plus maintenu et est considéré obsolète depuis combien de temps, déjà? (je sais, ce sont 2 dates différentes).
En gros: git est codé en C, mercurial en python. J'ai personnellement un fort biais envers les langages qui ont un vrai standard, et plusieurs implémentations dont aucune n'est "l'implémentation de référence".
Ça se discute probablement, mais vu que j'aime l'idée de pouvoir utiliser un logiciel 20 après avec les correctifs et améliorations apportées depuis, ben le fait d'être codé en python est déjà un désavantage monstre.
Maintenant, je veux bien croire qu'il puisse être supérieur à git, reste à savoir en quoi ça impacte l'utilisateur final?
Dans le cas, par exemple, de fossil, l'avantage sur git est clair: c'est une forge, pas un simple DVCS. De plus, c'est facile et robuste à migrer: un seul fichier à déplacer.
Dans le cas de mercurial? Je n'ai jamais vu d'arguments qui me semblent si importants.