[Info] Gestion de version pour usage personnel (et Git vs Mercurial)

Hibou57 · Le 19/03/2011, à 17:11

LOL, à propos de Git et Mercurial (ils sont souvent mis en balance ces deux là, ça cache quelque chose)

Git is MacGyver et plus bas Mercurial is James Bond

Je lis ça tout de suite Hiiii

Et ici : What is the Difference Between Mercurial and Git?

Le précédent lien a écrit :

I work on Mercurial, but fundamentally I believe both systems are equivalent.

La différence entre les deux, serait surtout technique alors ? Ce qui expliquerait la mise en avant des choix techniques fait pour l'un et l'autre, plutôt que la mise en avant des fonctionnalités ? (et il y a la question des GUI aussi, mais qui est une question à part).

-- EDIT --
Du même lien que plus haut (le second lien sur StackOverflow) :

Martin Geisler a écrit :

Git has a strong focus on mutating this history graph (with all the consequences that entails) whereas Mercurial does not encourage history rewriting, but it's easy to do anyway and the consequences of doing so are exactly what you should expect them to be (that is, if I modify a changeset you already have, your client will see it as new if you pull from me). So Mercurial has a bias towards non-destructive commands.

Dernière modification par Hibou57 (Le 19/03/2011, à 17:52)

Hibou57 · Le 19/03/2011, à 18:20

Hibou57 a écrit :

j'ai remarqué que les dépôts Mercurial consomment moins de place que les dépôts Git

Voilà l'explication :

What is the Difference Between Mercurial and Git?

Felipec -- dans le précédent lien a écrit :

There's one huge difference between git and mercurial; the way the represent each commit. git represents commits as snapshots, while mercurial represents them as diffs.

Ce qui ressemble plus à mon « truc » que j'avais fait sous Windows (l'archive était une archive de diffs)… la complexité en moins.

Enfin, les différences entre les deux s'éclairent.

Sinon, quelqu'un disait aussi :

Le même lien, mais un peu plus haut a écrit :

Git is a platform, Mercurial is "just" an application.

Ce qui me semble confirmé aussi par l'architecture : Mercurial plus monolithique que Git qui est plus composé d'éléments indépendants, comme un système ou un environnement.

-- EDIT --

La différente manière qu'ont les deux de créer les branches :

Même lien que plus haut

Le précédent lien a écrit :

To start a new branch, with Mercurial, you simply clone the repository to another directory and start developing. Then, you pull and merge. With git, you have to explicitly give a name to the new topic branch you want to use, then you start coding using the same directory.

Dernière modification par Hibou57 (Le 19/03/2011, à 18:34)

Gemnoc · Le 19/03/2011, à 18:43

Hibou57 a écrit :

Punaise, QT c'est KDE, pas GNOME!

Absolument pas.

KDE c'est Qt, mais l'inverse n'est pas vrai. J'utilise plusieurs applications programmées en Qt sous Ubuntu/GNOME, et elles ne présentent pas les mêmes dépendances volumineuses que les applications KDE. Elles s'intègrent également mieux que les applications KDE. Exemple : les applications Qt utilisent en général la fenêtre d'ouverture de fichiers de Nautilus/GNOME, alors que les applications KDE s'obstinent à utiliser celle de KDE.

Hibou57 a écrit :

Mais où ont-ils lu ou entendu que Qt est l'API standard d'Ubuntu ? C'est GTK + GNOME! Pas Qt + KDE!

Est-on obligé de tomber dans le dogmatisme sectaire?

Qt est un SDK graphique multiplateforme qui s'utilise très bien sous Linux, Windows et MacOS. Mark Shuttleworth a il me semble écrit qu'il était favorable à son utilisation pour le développement d'applications sous Ubuntu.

Hibou57 · Le 19/03/2011, à 19:59

Message en deux parties. Réponse à Gemmoc, puis ce que je passais en fait poster.

Première partie.
--------------------------------------------------------------------------------------------------------------

Gemnoc a écrit :

KDE c'est Qt, mais l'inverse n'est pas vrai

Oui, je m'ai trompé, j'ai écrit trop vite

Gemnoc a écrit :

J'utilise plusieurs applications programmées en Qt sous Ubuntu/GNOME, et elles ne présentent pas les mêmes dépendances volumineuses que les applications KDE

La version GTK de TortoiseHg : 8M
La version Qt de TortoiseHg : 80M, soit 10x plus.

Le même problème avec les applications GTK sous Windows, elle sont facilement 10 à 15 fois plus volumineuse que exactement les mêmes applications GTK sous GNOME/Ubuntu.

Gemnoc a écrit :

Est-on obligé de tomber dans le dogmatisme sectaire?

Ce n'est pas par dogmatisme, c'est des raisons techniques (voir la réponse juste ci-dessus pour un exemple).

Gemnoc a écrit :

Qt est un SDK graphique multiplateforme qui s'utilise très bien sous Linux, Windows et MacOS

Sous Linux, c'est soit Qt, soit GTK, selon le cas; sous Windows, c'est la GDI (pas Qt ni GTK), sous Mac, c'est Cocoa (pas Qt ni GTK non-plus).

Gemnoc a écrit :

Mark Shuttleworth a il me semble écrit qu'il était favorable à son utilisation pour le développement d'applications sous Ubuntu.

Quand l'API GUI d'Ubuntu sera Qt, ce sera différent, mais ce n'est actuellement pas encore le cas (et on ne sait même pas si ça le sera vraiment un jour).

Seconde partie.
--------------------------------------------------------------------------------------------------------------

Liste de lecture à propos de Git vs Mercurial, puis conseils rapides, avec peu de chances de me tromper à leur sujet.

Git vs. Mercurial: Please Relax [2008]
The Differences Between Mercurial and Git [2008]
Mercurial, Subversion, and Wesley Snipes [2009]
Mercurial vs Git [2009]

Et deux documents utilitaires à propos de Mercurial :

Alors, les conseils quand vient le temps de faire un choix :

Vais-je travailler seul ou en équipe ?
L'administration sera t-elle une question ou pas ?
Le contexte cela t-il plutôt GUI ou CLI ?

Si vous travaillez seul(e), Mercurial serait plutôt l'option; dans le cas contraire, préférez Git. Les deux questions suivantes, sont en fait plus ou moins liées à la première : si vous travaillez en équipe, et même avec de nombreux contributeurs/rices, surtout s'il y a beaucoup de branches à gérer, alors l'administration sera incontournables, et Git s'imposera comme incontournable, dans le cas contraire, Mercurial viendra sans surcout inutiles pour vos besoins de base. Et la troisième est liée à la seconde : dans le cas ou le besoin d'administration semblera inévitable, mieux vaudra s'attendre à passer beaucoup de temps en ligne de commande dans tous les cas, et pas seulement à cause de Git, et ce n'est pas un hasard si le nombre de GUI disponibles (tant bien que mal) pour Mercurial est plus important que pour Git.

Bref, il faut bien identifier vos besoins et avoir les idées claires à leur sujet (ne pas être indécis, et ne pas laisser trop de place aux « peut-être »).

Je renomme le sujet, vu la tournure qu'il a pris.

Dernière modification par Hibou57 (Le 19/03/2011, à 20:02)

xapantu · Le 19/03/2011, à 20:09

Hibou57 a écrit :

Gemnoc a écrit :
J'utilise plusieurs applications programmées en Qt sous Ubuntu/GNOME, et elles ne présentent pas les mêmes dépendances volumineuses que les applications KDE
La version GTK de TortoiseHg : 8M
La version Qt de TortoiseHg : 80M, soit 10x plus.
Le même problème avec les applications GTK sous Windows, elle sont facilement 10 à 15 fois plus volumineuse que exactement les mêmes applications GTK sous GNOME/Ubuntu.

(Je ne vois pas tellement le rapport avec la citation.)

Mouais, mais es-tu sûr que ce n'est pas simplement à cause du système de dépendances ?

Gemnoc a écrit :
Qt est un SDK graphique multiplateforme qui s'utilise très bien sous Linux, Windows et MacOS
Sous Linux, c'est soit Qt, soit GTK, selon le cas;

Ou plein d'autres trucs… (efl par exemple)

sous Windows, c'est la GDI (pas Qt ni GTK), sous Mac, c'est Cocoa (pas Qt ni GTK non-plus).

C'est faux, on peut très bien utiliser GTK+ ou Qt sur Windows ou Mac. Regarde par exemple Opera (Qt), Gimp (GTK), Inkscape (GTK), VLC (Qt)…

Gemnoc a écrit :
Mark Shuttleworth a il me semble écrit qu'il était favorable à son utilisation pour le développement d'applications sous Ubuntu.
Quand l'API GUI d'Ubuntu sera Qt, ce sera différent, mais ce n'est actuellement pas encore le cas (et on ne sait même pas si ça le sera vraiment un jour).

http://www.markshuttleworth.com/archives/568

On peut très bien avoir des applicationq de base dans Ubuntu en GTK et en Qt.

Dernière modification par xapantu (Le 19/03/2011, à 20:11)

Hibou57 · Le 19/03/2011, à 20:48

On peut ouvrir un sujet séparé pour ça ? Merci.

Je me posais aussi la question du type de fichiers qu'il est possible d'utiliser. je disais dans le premier message, que les système de contrôle de version et d'historique, ne sont pas seulement utiles aux développeur, et que de même que le Net, à ses débuts un domaine d'informaticiens, s'est largement ouvert à d'autre publique, j'imagine qu'à l'avenir les système de contrôle de version et d'historique apparaitront utiles à d'autres gens que seulement aux auteurs de programmes.

Seulement, ça pose la question de savoir si oui ou non ils peuvent correctement traiter des fichiers qui seraient moins souvent des fichiers texte. Pour des images SVG par exemple, sous réserve qu'elles ne soient pas sous un format compressée comme le SVGZ, ça pourrait aller, mais pour des images bitmaps, ça n'irait plus. Encore plus flagrant avec l'audio, la vidéo, et sûrement d'autres choses. Il est connu que l'utilitaire diff lui-même, n'aime pas trop les fichiers binaires.

Il semblerait que l'algorithme de comparaison des fichiers utilisé par Mercurial soit mieux adapté que celui de Git à ce type de fichiers. C'est un heureux hasard si ça se confirme et si c'est vérifié, parce que ce type de fichier se trouveraient plus probablement dans des travaux personnel : on voit bien moins souvent des travaux collaboratif sur de la retouche de photos (juste une exemple).

Gemnoc · Le 19/03/2011, à 21:50

Hibou57 a écrit :

On peut ouvrir un sujet séparé pour ça ? Merci.

Le fil et ta démarche m'intéressent, même si je ne suis pas programmeur. Mais désolé, voir des énormités comme tu continues à le faire sur les GUI, ça ne passe pas, et je suis content de constater que je ne suis pas le seul à le penser.

Bon, j'ai dit ce que j'avais à dire, et de plus je suis certain d'après tes réponses qu'avec ton état d'esprit, ouvrir un autre sujet serait une perte de temps. Je retourne donc en mode silencieux.

Hibou57 · Le 19/03/2011, à 22:53

Attend, juste après, mais d'abord :

Un lien que j'ai oublié de poster Hg Init: a Mercurial tutorial. Avec ça, je crois que le tour a été fait.

Bon, en peu de mots au sujet de l'autre question. Ce n'est pas moi qui ai choisi ce que sont les plateformes, et une fois posé le principe de respecter les plateformes sous-jacentes, ce n'est pas être borné que de faire remarquer ce qu'elles sont. Sinon, si c'est le principe de respecter la plateforme sous-jacente qui est contesté, c'est encore une autre question.

Pour Qt et GTK en propre, quand je vois la différence de taille des applications Qt sous GNOME, je n'invente rien, il suffit de tester, comme avec l'exemple de TortoiseHg. Je ne vais pas inventer autre chose alors que c'est ce que je constate.

Qt « respecte mieux la plateforme sous-jacente » que ne le fait GTK, donc il devrait poser moins de problème. Mais c'est en théorie, moins souvent en pratique; juste que sous Mac tout de même, la différence serait apparemment plus flagrante, mais je n'ai pas de Mac moi même, je fais ici juste confiance à ce que m'en ont dit des utilisateurs de Mac. Qt, peut sous Windows, potentiellement mieux respecter la GUI sous jacente que ne le fait GTK, mais c'est important de souligner potentiellement (parce que souvent, les applications Qt sous Windows, sont utilisées pour en mettre plein la vue, et pas pour utiliser l'option de respecter le style XP par exemple).

Tu donnais l'exemple d'Opera, et justement, c'est un bon exemple de la raison pourquoi en général ça ne marche pas : Opera, c'est un logiciel édité par une société commerciale, avec des employés salariés, qui travail à plein temps sur ce navigateur. Rien à voir avec des logiciels distribués gratuitement pour lesquels « plus vite c'est fait, mieux c'est ». Et justement une comparaison ici, sous Windows (quand j'y étais), une simple application Qt comme VMPK (un clavier MIDI virtuel), pesait autant que tout un navigateur comme Opera, qui est aussi en Qt pourtant. En pratique, c'est plutôt l'exemple de VMPK qui se produit, les cas comme Opera étant minoritaire, parce qu'ils demandent plus de travail.

J'ai essayé d'installer quelques applications Qt sous GNOME, ce que j'en ai vu m'a suffit. Pourtant j'utilise Opera. Mais Opera, c'est différent, pour les raisons que je donne plus haut. Le même commentaire serait certainement valable à propos de Skype.

Dernière modification par Hibou57 (Le 19/03/2011, à 22:57)

Le Farfadet Spatial · Le 20/03/2011, à 04:46

Salut à tous !

Hibou57 a écrit :

ce n'est pas parce qu'il est intéressant (pour la modélisation et la formalisation) qu'il est bon pour tout, et pour ça en particulier.

Me dire ça à moi, qui, notamment sur ce forum, ne cesse de dire qu'il n'y a pas de langage parfait et qu'il faut choisir le plus approprié pour le cas particulier dans lequel on se trouve – entre autres exemples, voir cet épinglé. Enfin, tu es un nouveau venu, alors je ne le prends pas mal !

C'est entièrement écrit en Haskel ou seulement certaines parties ?

Entièrement en Haskell et c'est très performant.

C'est portables sur Windows et Mac ? Parce qu'un système de gestion de version, c'est à mettre au même niveau fondamental qu'un format d'archive ou un format de document… il vaut mieux que ça puisse être utilisé sur toutes les plateformes avec la même facilité/efficacité.

Me dire ça à moi, qui ne cesse de dire que la portabilité est essentielle. Décidément, ces petits jeunes ne respectent rien !

Bon, plus sérieusement, je travaille sur des codes qui fonctionnent sous GNU/Linux, certes, mais aussi *BSD, Solaris, AIX, MacOS X et Microsoft Windows – sur cette dernière plateforme, je dois reconnaître que, personnellement, je me contente de m'assurer que ça compile et que ça fonctionne dans les grandes lignes. Les solutions que je propose sont donc toujours au moins utilisable sur ces six plateformes, généralement plus. En l'occurrence, MacOS X et Microsoft Windows font partie des plateformes officiellement supportées par Darcs. Il y a une entrée dédiée à Microsoft Windows dans le Wiki de Darcs.

À bientôt.

Le Farfadet Spatial

Hibou57 · Le 07/08/2011, à 16:18

Hibou57 a écrit :

Sous Windows, j'avais commencé à créé un mini système de sauvegarde de versions, à usage personnel, et non pas pour usage collaboratif, comme le sont les plus connu et qui sont surtout conçus pour des utilisations distantes.
Il me semblait que c'est une bonne idée qui servirait à tout le monde, et pas seulement dans le logiciel; ça serait autant utile aux écrivains, aux graphistes, musiciens, puis tant d'autres; beaucoup de monde.
Je ne l'avais pas très bien fait, donc je prévoyais de le refaire entièrement, et puis événement qu'est de quitter Windows pour migrer vers Ubuntu, alors je me disais que la première chose à faire, c'est de demander si ça n'existe pas déjà sous Ubuntu, histoire de ne pas perdre du temps à refaire ce qui existe peut-être déjà.
En connaissez-vous ? Ça existe déjà à votre connaissance ?
Si ça n'existe pas déjà, tant-pis, je me re-pencherai plus tard sur la question d'en re-concevoir un.

Le sujet était partit sur une solution Git ou Mercurial, mais j’ai découvert hier quelque chose qui s’approche plus directement de ce que j’avais fait sous Windows : Duplicity. Il sera installé par défaut dans de futures versions d’Ubuntu (c'est comme ça que je l'ai découvert), à travers Déjà-Dup, son interface de haut niveau.

C’est plus proche de ce que je faisais comparé à Mercurial ou Git, parce qu’il n’y a pas de notion de branches et compagnies, et comparé à RSync, parce que ça n’enregistre que les différences, ce qui est permet de restaurer à une certaine date.

Par contre il subsiste une différence : Duplicity génère un fichier séparé pour chaque sauvegarde des différences (je n’utilisais qu’un seule fichier d’archive, pour que ce soit plus monolithique).

L’occasion aussi de parler de Duplicity et Dejà-Dup : si vous avez déjà utilisé Dejà-Dup, je vous suggère de découvrir Duplicity tout de même (qui est interfacé par Dejà-Dup), parce que Dejà-Dup est limité dans le sens où il ne peut être configuré que pour une seule opération de sauvegarde. Si vous passez par Duplicity directement, vous serez moins restreint(e) pour pourrez définir des opérations de sauvegardes répertoire-par-répertoire, et de même, restaurer des répertoires individuellement.

C’est quelque qu’il manque à Dejà-Dup à mon avis : la possibilité de définir plusieurs ensemble Source + Sauvegarde.

Dernière modification par Hibou57 (Le 07/08/2011, à 16:25)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 19/03/2011, à 17:11

Re : [Info] Gestion de version pour usage personnel (et Git vs Mercurial)

#27 Le 19/03/2011, à 18:20

Re : [Info] Gestion de version pour usage personnel (et Git vs Mercurial)

#28 Le 19/03/2011, à 18:43

Re : [Info] Gestion de version pour usage personnel (et Git vs Mercurial)

#29 Le 19/03/2011, à 19:59

Re : [Info] Gestion de version pour usage personnel (et Git vs Mercurial)

#30 Le 19/03/2011, à 20:09

Re : [Info] Gestion de version pour usage personnel (et Git vs Mercurial)

#31 Le 19/03/2011, à 20:48

Re : [Info] Gestion de version pour usage personnel (et Git vs Mercurial)

#32 Le 19/03/2011, à 21:50

Re : [Info] Gestion de version pour usage personnel (et Git vs Mercurial)

#33 Le 19/03/2011, à 22:53

Re : [Info] Gestion de version pour usage personnel (et Git vs Mercurial)

#34 Le 20/03/2011, à 04:46

Re : [Info] Gestion de version pour usage personnel (et Git vs Mercurial)

#35 Le 07/08/2011, à 16:18

Re : [Info] Gestion de version pour usage personnel (et Git vs Mercurial)

Pied de page des forums