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

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

-- EDIT (3) 2011-08-07 --
Duplicity, qui vient également avec Déjà-Dup, est une solution plus proche de la requête originale. Voir à ce sujet, le message #36.
-- FIN EDIT --

-- EDIT (2) 2011-03-19
Lectures :

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 :

Voir également la seconde partie du message #29

Le sujet est également renommé, pour mieux refléter son contenu effectif.
-- FIN EDIT --

-- EDIT (1) 2011-03-19
Attention : il est fait référence dans ce sujet, à TortoiseHg, une GUI pour Mercurial. L'installation de TortoiseHg via les paquets officiels, installe une version tout à fait obsolète. La version actuelle est la version 2.0, et non pas la version 1.1. Voir messages #21 et #22.
-- FIN EDIT --

-- Message d’origine --

re-Hello,

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.

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

Bousky · Le 17/03/2011, à 14:39

C'est très simple : au moment d'enregistrer, tu utilises enregistrer sous (Ctrl + Maj + S), en nommant tes fichiers sous la forme « nom_du_fichier.aaaa-mm-jj.ext » ou « nom_du_fichier.v#.ext », ou un mélange des deux. Tu peux éventuellement le faire au niveau d'un dossier. Tu peux utiliser un script de ce genre :

#!/bin/bash

while [ "$1" ] ; do
    cp -a "$1" ${1%.*}.`date +%F`.${1##*.}
    shift
done

Celui-ci bug s'il n'y a pas d'extension. Il prends des fichiers sous la forme « fichier.ext » en fait une copie sous la forme « fichier.aaaa-mm-jj.ext ». Il marche aussi sur les dossiers.

Dernière modification par Bousky (Le 17/03/2011, à 14:41)

Karl_le_rouge · Le 17/03/2011, à 14:43

1. utilise un VCS moderne comme git ou mercurial, ça fonctionne très bien y compris pour une utilisation mono-utilisateur et ce sera beaucoup plus efficace en espace de stockage, robustesse, etc ...
2. en gros, tu veux réécrire RCS en beaucoup moins bien

RegisBurin · Le 17/03/2011, à 15:00

Bousky a écrit :

C'est très simple : au moment d'enregistrer, tu utilises enregistrer sous (Ctrl + Maj + S), en nommant tes fichiers sous la forme « nom_du_fichier.aaaa-mm-jj.ext » ou « nom_du_fichier.v#.ext », ou un mélange des deux. Tu peux éventuellement le faire au niveau d'un dossier. Tu peux utiliser un script de ce genre :
...

C'est ce que je fais (niveau graphisme, textes, etc...) mais si c'est clair (visuellement) et efficace (moyennant une certaine rigueur) ça devient vite lourd et rébarbatif...

Je pense que Hibou57 parle de quelque chose de plus généraliste et assisté (qui fonctionnerait comme les "révisions" dans un fichier d'une suite bureautique), ou, du moins, fournissant un historique de révision (comme un wiki)...

Comme ce que l'on peut trouver dans les GPAO/ERP au niveau des modules de gestion d'indices de plans, mais utilisable quels que soient les types de fichiers... En fait, il faudrait détourner (et hyper-simplifier) un ERP pour ça ??! non ?

Je prend l'exemple de mon taf (dessinateur indus/méthodes). La boite dans laquelle je bosse utilise un truc super fermé dont je tairais le nom (ça commence par P et fini par M... avec un L au milieu ). En fait (dans ma fonction) j'utilise son module de gestion documentaire, qui me permet d'avoir, sur un projet donné, une arborescence des fichiers de conception (cahier des charges, plans, nomenclatures...), et de production (gammes, procédures, instructions...). Tout ça avec une gestion des indices sans (presque) que j'ai à m'en préoccuper, et donc un archivage et un historique auto des documents (toutes extensions confondus) importer dans le système. Et me permettant de les consulter (dans un viewer), ou de les ouvrir avec le soft associé... Si, au final, cela fonctionne exactement pareil que ce que tu décris, et n'empêche pas cette phase "d'indiçage" et de classement (sous traitée par le soft) l'outil utile dans l'histoire, c'est l'interface graphique qui synthétise tout ça, et permet de "retrouver ses petits" facilement.

C'est clair que principe serait super intéressant sur des fichiers de graphismes, musique, etc...

@+

Dernière modification par RegisBurin (Le 17/03/2011, à 15:02)

Hibou57 · Le 17/03/2011, à 15:01

Bousky a écrit :

C'est très simple : au moment d'enregistrer, tu utilises enregistrer sous (Ctrl + Maj + S), en nommant tes fichiers sous la forme « nom_du_fichier.aaaa-mm-jj.ext » ou « nom_du_fichier.v#.ext », ou un mélange des deux. Tu peux éventuellement le faire au niveau d'un dossier. Tu peux utiliser un script de ce genre : […]

Merci pour ta réponse (et en plus, complète), ça fait zizir, mais ça ne conviendrait pas. le système que j'avais fait sous Windows n'enregistrait que les différences entre les fichiers (par contre, les versions initiales étaient stockées entièrement, évidement, c'était nécessaire). Le truc, c'est que je voulais quelque chose qui soit sans dépendances, une application monolithique et légère, qui intégre sont propre diff et son propre archiveur. L'archiveur, c'est parce que les successions de diff étaient enregistrés dans une archive compressée, c'est à dire que contrairement à CVS ou SVN, ça ne laissait rien dans les répertoires, il n'y avait qu'un seul fichier pour ce système, qui était cette archive. Puis il y avait une commande qui permettrait de faire un retour en arrière. Chaque archivage pouvait être accompagné d'un commentaire. Bref, c'est juste pour dire que ça dépassait la simple copie de fichier. Ça marchait, mais je trouvais que je l'avais mal conçu, alors je voulais le recommencer entièrement.

Karl_le_rouge a écrit :

1. utilise un VCS moderne comme git ou mercurial, ça fonctionne très bien y compris pour une utilisation mono-utilisateur et ce sera beaucoup plus efficace en espace de stockage, robustesse, etc ...
2. en gros, tu veux réécrire RCS en beaucoup moins bien

RCS ? C'est quoi ? Je vais me renseigner dessus.

Git ou Mercurial, oui, ce sont les nouveaux, je ne connais que les deux anciens, CVS et SVN. Je vais me pencher sur les deux nouveaux, pour voir s'ils me conviennent.

Je me renseigne de suite.

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

Airballman · Le 17/03/2011, à 15:03

Pour un usage perso (et même plus) , git est parfait.

Super simple, il va te falloir genre 10 minutes pour comprendre comment ça marche . PAr besoin de serveur distant ni rien d'autre

Hibou57 · Le 17/03/2011, à 15:08

RegisBurin a écrit :

Je pense que Hibou57 parle de quelque chose de plus généraliste et assisté (qui fonctionnerait comme les "révisions" dans un fichier d'une suite bureautique), ou, du moins, fournissant un historique de révision (comme un wiki)...

Vi! C'est ça!

Ça parle beaucoup de Git ici, je file le voir.

RegisBurin a écrit :

En fait, il faudrait détourner (et hyper-simplifier) un ERP pour ça ??! non ?

Je ne connais pas les ERP, mais je vais renseigner.

RegisBurin a écrit :

Je prend l'exemple de mon taf (dessinateur indus/méthodes). La boite dans laquelle je bosse utilise un truc super fermé

Alors ça, c'est un point important justement : je veux que le format utilisé par le système soit ouvert. C'est pour ça que l'idée du diff + archive me plaisait. Si l'application tombait en carafe pour une raison XYZ, rien ne serait perdu, et il serait toujours possible d'en récupérer quelque chose.

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

Airballman · Le 17/03/2011, à 15:11

En plus c'est fait par copin Linus alors bon ^^

Pour plus d'infos, j'avais déjà demandé de l'aide ici dans le temps :

Hibou57 · Le 17/03/2011, à 15:13

Airballman a écrit :

En plus c'est fait par copin Linus alors bon ^^

Linus, c'est pas mon copain, j'aime pas ce gars là (mégalo, capitaliste, entre autres). Mais le prend pas pour toi… tu pouvais ne pas savoir

Je vais lire ton lien.

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

Karl_le_rouge · Le 17/03/2011, à 15:20

1. Linus ne maintient plus Git mais Junio Hamano si
2. Certes c'est un connard, mais un connard compétent *et* avec de l'humour (cherches l'origine du nom Git )
3. RCS est l'ancètre des systèmes de révisions toujours utilisé, intégré à Unix, entre autre CVS est une surcouche à RCS.

Airballman · Le 17/03/2011, à 15:21

Bin moi j'aime bien les capitalistes ^^, c'est ceux qui font tourner le monde après tout.

Après, tant que mon outil est efficace (et si possible gratuit) ça me suffit; j'ai jamais été vraiment porté vers le culte de la personnalité .
Ceci dit c'est souvent un atout de poids vu les gens qui traînent ici

Bousky · Le 17/03/2011, à 17:26

RegisBurin a écrit :

La boite dans laquelle je bosse utilise un truc super fermé dont je tairais le nom (ça commence par P et fini par M... avec un L au milieu )

Le PLM ? Ah non, c'est pas ça…

Hibou57 · Le 17/03/2011, à 17:40

En fait, plutôt que Git, j'ai opté pour Mercurial.

Je m'explique sur les raisons.

Techniquement parlant, la conception de Mercurial me semble meilleure, mieux pensée. Il est en C + Python, tandis que Git est en C + Bash + Perl + Python. Il semble d'ailleurs être confirmé que Git sous Windows, ce n'est pas terrible (je n'envisage pas de revenir à Windows, mais j'estime que c'est une plateforme qu'on ne peut pas ignorer).

Mercurial semble disposer de la capacité de créer des repositorie compressés… exactement la fonctionnalité de ce que j'avais créé avec mon bidule sous Windows. Cependant, je n'ai pas encore trouvé l'option (je sais seulement qu'elle existe). La même chose ne semble pas exister avec Git, et même hors-compression, j'ai remarqué que les dépôts Mercurial consomment moins de place que les dépôts Git (suite à une évaluation rapide, je ne m'engage pas plus que ça à son sujet pour l'instant, et je ne serais pas surpris que ça reste discutable).

Concernant l'UI. Git propose une GUI en Tk… une horreur, je ne veux plus la voir. Il existe plusieurs GUI pour Mercurial pour toutes les plateformes : Mac OSX, Windows, GTK, Qt. J'ai installé tortoisehg [1] et tortoisehg-nautilus [1] qui me semble vraiment bon. Je n'aime pas trop le menu contextuel, mais ça passe. Il ajoute également un onglet dans les propriété des fichiers sous Nautilus, qui permet de voir sous quelle révision actuelle se trouve un fichier.

Il existe encore d'autres GUI pour Mercurial sous Ubuntu, mais la majorité reposent sur Qt, donc sont plutôt faite pour KDE, et je me suis fixé comme règle de n'installer aucune application KDE sous GNOME (non pas que je n'aime pas KDE, mais c'est que les applications Qt/KDE sous GNOME ça ne va pas). Par exemple CuteHG, qui n'est d'ailleurs plus maintenu par son auteur et que personne ne semble avoir repris (encore un aléas de l'open-source).

Voilà. Maintenant que j'ai fait un choix, je m'occupe d'apprendre à correctement m'en servir.

Si des gens ont des informations auxquelles je ne penserais pas, concernant le choix entre Git et Mercurial, dites le quand-même. Si je fais une erreur de choisir Mercurial, j'aime mieux le savoir le plus tôt possible.

[1] Il y a dans l'un ou l'autre de ces paquets, un bug de dépendance. Ils dépendent de python-iniparse, qui n'est pourtant pas listé dans leurs dépendances et n'est donc pas installé automatiquement en même temps. Vous devez donc penser à l'installer avant ou ensuite, sinon TortoiseHG ne peut pas fonctionner.

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

Airballman · Le 17/03/2011, à 17:53

Je n'ai jamais testé mercurial. L'argumentaire que tu avances ne peut que motiver à tester .

Niveau simplicité d'utilisation, ça donne quoi ? (perso je trouve svn vriament lourd à utiliser, et c'est pour ça que j'étais passé à git).

Hibou57 · Le 17/03/2011, à 18:13

J'ai oublié : l'installation de base Mercurial prend elle également, deux fois moins de place que celle de Git. Ce qui est encore un bon signe. Et même avec la GUI TortoiseHG, Mercurial reste encore en dessous question occupation.

Airballman a écrit :

Niveau simplicité d'utilisation, ça donne quoi ?

Ça m'a l'air assez simple, même si le nombre de commandes Mercurial est apparemment plus important que le nombre de commandes Git (mais une GUI, ça change tout). Voir plus loin, je poste le résultat de --help pour les deux.

Il faut voir le Workbench, accessible depuis le menu contextuel des dossiers sous Nautilus. Voir copie d'écran plus loin (pas de moi, mais du site officiel de TortoiseHG).

J'en re-dirai plus, plus tard. Là c'est encore trop tôt.

yannick@douda-yannick:~$ git --help
usage: git [--version] [--exec-path[=GIT_EXEC_PATH]] [--html-path]
           [-p|--paginate|--no-pager] [--no-replace-objects]
           [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE]
           [--help] COMMAND [ARGS]

The most commonly used git commands are:
   add        Add file contents to the index
   bisect     Find by binary search the change that introduced a bug
   branch     List, create, or delete branches
   checkout   Checkout a branch or paths to the working tree
   clone      Clone a repository into a new directory
   commit     Record changes to the repository
   diff       Show changes between commits, commit and working tree, etc
   fetch      Download objects and refs from another repository
   grep       Print lines matching a pattern
   init       Create an empty git repository or reinitialize an existing one
   log        Show commit logs
   merge      Join two or more development histories together
   mv         Move or rename a file, a directory, or a symlink   pull       Fetch from and merge with another repository or a local branch
   push       Update remote refs along with associated objects
   rebase     Forward-port local commits to the updated upstream head
   reset      Reset current HEAD to the specified state
   rm         Remove files from the working tree and from the index
   show       Show various types of objects
   status     Show the working tree status
   tag        Create, list, delete or verify a tag object signed with GPG

See 'git help COMMAND' for more information on a specific command.

yannick@douda-yannick:~$ hg --help
Mercurial, système de gestion de sources distribué

liste des commandes :

 add          add the specified files on the next commit
 addremove    add all new files, delete all missing files
 annotate     show changeset information by line for each file
 archive      create an unversioned archive of a repository revision
 backout      reverse effect of earlier changeset
 bisect       recherche de "changesets" par dichotomie
 branch       set or show the current branch name
 branches     list repository named branches
 bundle       create a changegroup file
 cat          output the current or given revision of files
 clone        make a copy of an existing repository
 commit       commit the specified files or all outstanding changes
 copy         mark files as copied for the next commit
 diff         diff repository (or selected files)
 export       dump the header and diffs for one or more changesets
 forget       forget the specified files on the next commit
 grep         search for a pattern in specified files and revisions
 heads        show current repository heads or show branch heads
 help         show help for a given topic or a help overview
 identify     identify the working copy or specified revision
 import       import an ordered set of patches
 incoming     show new changesets found in source
 init         create a new repository in the given directory
 locate       locate files matching specific patterns
 log          show revision history of entire repository or files
 manifest     output the current or given revision of the project manifest
 merge        merge working directory with another revision
 outgoing     show changesets not found in the destination
 parents      show the parents of the working directory or revision
 paths        show aliases for remote repositories
 pull         pull changes from the specified source
 push         push changes to the specified destination
 recover      roll back an interrupted transaction
 remove       remove the specified files on the next commit
 rename       rename files; equivalent of copy + remove
 resolve      redo merges or set/view the merge status of files
 revert       restore individual files or directories to an earlier state
 rollback     roll back the last transaction (dangerous)
 root         print the root (top) of the current working directory
 serve        start stand-alone webserver
 showconfig   show combined config settings from all hgrc files
 status       show changed files in the working directory
 summary      summarize working directory state
 tag          add one or more tags for the current or given revision
 tags         list repository tags
 tip          show the tip revision
 unbundle     apply one or more changegroup files
 update       update working directory (or switch revisions)
 verify       verify the integrity of the repository
 version      output version and copyright information

sujets d'aide supplémentaires :

 config       Configuration Files
 dates        Date Formats
 patterns     File Name Patterns
 environment  Environment Variables
 revisions    Specifying Single Revisions
 multirevs    Specifying Multiple Revisions
 revsets      Specifying Revision Sets
 diffs        Diff Formats
 templating   Template Usage
 urls         URL Paths
 extensions   Using additional features
 hgweb        Configuring hgweb
 glossary     Glossary

utiliser "hg -v help" pour afficher les alias et les options globales

Workbench de TortoiseHG

Ci-dessus : Workbench de TortoiseHG (cette copie d'écran n'est pas de moi)

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

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

Re-

Réponse à la question précédemment posée : Oui, c'est très simple à utiliser, même si ça pourrait être encore amélioré; par exemple j'aimerais que la commande Commit du menu contextuel de Nautilus, coche automatiquement tous fichiers nouvellement créés, afin de ne pas oublier de les ajouter, ou encore qu'il soit possible d'accéder à l'historique des modifications d'un fichier directement depuis un menu contextuel sur le fichier lui-même, sans avoir à ouvrir l'Explorateur de Dépôt pour y retrouver le fichier en question. Mais ce sont des feature-requests, c'est autre chose.

Sinon à part ces vœux, c'est tout à fait simple à utiliser, et c'est baucoup plus agréable que l'interface Tk de Git. Resterait peut-être à plus parler de comparaisons des fonctionnalités liées au travail avec les versions. Mais là je ne peux rien en dire comme ça, il faudrait que des gens connaissant vraiment bien les deux viennent en parler. Juste comme ça, à vu de nez, je dirai qu'il ne manque rien à Mercurial sur ce point.

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

Hibou57 · Le 18/03/2011, à 21:07

Airballman a écrit :

Je n'ai jamais testé mercurial. L'argumentaire que tu avances ne peut que motiver à tester .

Alors, t'as essayé ? T'en pense quoi ?

De mon côté j'ai juste remarqué quelques petits bugs de l'intégration dans Nautilus. L'entrée de menu « Explorateur de dépôt » (alias Workbench) et l'entrée « Commit… », ne s'affichent pas toujours; il faut parfois ouvrir deux ou trois fois le menu contextuel du dossier pour le voir apparaître, alors qu'il y a bien un dépôt dans le dossier.

Le problème ne se présente pas avec l'entrée de menu TortoiseHg.

Toujours avec Nautilus, à la suite d'un Commit, normalement les fichiers "commités" doivent avoir un petit emblème qui représente une coche sur un rond vert. L'emblème n'apparait pas toujours, et il faut parfois faire plusieurs rafraichissements de la vue du dossier avant que les emblèmes n'apparaissent.

Ce qui est bizarre, c'est que les emblème en question ne sont pas définis dans la panneau des emblèmes de Nautilus, alors je me demande si ça n'utilise pas la même technique que pour TortoiseSVN sous Windows, avec les overlay icons.

Pour l'instant et en dehors de ces bugs de l'intégration à Nautilus, rien à signaler de mal, tout marche bien.

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

Le Farfadet Spatial · Le 18/03/2011, à 22:11

Salut à tous !

Personnellement, après avoir utilisé Mercurial, je suis passé à Darcs : au moins aussi simple d'utilisation, au moins aussi léger. En revanche, la théorie des patchs permet à Darcs d'avoir encore plus de souplesse. De plus, il est développé en Haskel et je soutiens ce langage. Je pense que ça vaut la peine de l'essayer. Cela dit, Mercurial est un bon logiciel.

À bientôt.

Le Farfadet Spatial

Hibou57 · Le 19/03/2011, à 07:45

Le Farfadet Spatial a écrit :

De plus, il est développé en Haskel et je soutiens ce langage.

Je sais que Haskel est intéressant (sinon y a SML, c'est bien aussi Cheese ), mais faut pas tout confondre, 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.

C'est entièrement écrit en Haskel ou seulement certaines parties ? 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é.

Je le regarderai plus tard.

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

Hibou57 · Le 19/03/2011, à 08:47

Re-

Un autre défaut de TortoiseHg, mais qui ne pas l'empêche de fonctionner correctement, obviously, se trouve dans la documentation : elle suppose principalement que l'utilisateur/rice de TortoiseHg est sous Windows, et elle fait référence à une commande, nommée thg, qui semble absente de l'installation sous Ubuntu. Mais cette commande qui sert à lancer le Workbench, est heureusement accessible par les menu contextuels de Nautilus.

-- EDIT -- Un autre exemple d'erreur dans la documentation.

2.1. What is TortoiseHg?

Le précédent lien a écrit :

TortoiseHg is primarily written in Python and PyQt

Non, sous Ubuntu, pyqt n'est pas installé, je viens de le vérifier. La version Ubuntu repose sur pygtk. Ils auraient dut dire « TortoiseHg is primarily written in Python and PyQt or PyGTK, depending on platform ».

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

Hibou57 · Le 19/03/2011, à 09:05

Re-re-

La version de TortoiseHg fournie par les paquets officiels est obsolète !. La dernière version n'est pas la version 1.1, mais la version 2.0.

J'ajoute un avertissement au premier message de ce sujet.

Pour installer la version à jour sous Maverick, voir

TortoiseHg PPA Packagers: Releases
Mercurial PPA Packagers: Releases
python-iniparse, la dépendance manquante à installer soi-même
Installing TortoiseHG 2.0 under Ubuntu 10.10 (Maverick)

Les trois premiers liens étant les plus importants; le second n'est qu'informatif.

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

Hibou57 · Le 19/03/2011, à 09:39

Ben voilà, ils ont mis les deux pieds dedans!

Je m'explique. La version de TortoiseHg du dépôt officiel, repose sur pygtk… malheureusement, elle est obsolète comme expliquée plus haut. Mais la version à jour de TortoiseHg pour Ubuntu, repose sur pyqt. Punaise, QT c'est KDE, pas GNOME!

Résultat : l'installation légère qu'était TortoiseHg pour Ubuntu, passe d'un coup à 80M.

Et blam, ils ont mis les deux pieds dans la connerie qu'il ne fallait pas faire.

Quand on parlait des choses à ne pas faire sur un autre sujet (un sujet sur Mono), … ben voilà encore un bel exemple de choses à ne pas faire.

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

Du coup, je ne sais plus quoi faire. Ça ne remet pas en cause le choix de Mercurial, car Mercurial est le système de base en ligne de commande, qui ne doit pas être confondu avec la GUI. Mais il faut bien une GUI quand-même. Seulement laquelle alors ? Toutes les autres reposent sur Qt (alors que KDE est nettement moins répandu que GNOME, c'est vraiment du grand n'importe), et les autres qui reposaient sur GTK, en sont plus maintenues (leurs auteurs se sont apparemment lassé).

Des idées ?

Sinon, oui, la nouvelle version fonctionne, je l'ai installé pour la tester, mais je ne pense pas rester avec, je ne peux quand-même pas cautionner un si mauvais choix technique.

-- EDIT -- Le seule disponible encore en GTK, c'est hgview, mais c'est bugé au point de planter directement au démarrage. Sinon toutes les autres GUI sont en Qt Furax . Ça irait si Qt était actuellement l'API de Ubuntu, mais encore une fois, ça n'est pas le cas actuellement.

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

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

Pour poursuivre et essayer de débroussailler.

Les bugs dont je parlait plus haut, ceux concernant l'intégration à Nautilus, existent toujours, même avec cette nouvelle version. Donc il n'y a pas d'avantages de ce point de vue, à prendre la dernière version, et celle du dépôt officiel d'Ubuntu, n'est pas moins obsolète en ce qui concerne ces bugs.

Mais il existe une autre différence, avec Mercurial

TortoiseHg 2.0 repose sur Mercurial 1.8 et supérieur
TortoiseHg 1.1 repose sur Mercurial 1.0 et supérieur

Il faudrait donc savoir si oui ou non il existe des différence significatives entre la Mercurial 1.0 et Mercurial 1.8.

Si des gens ont des infos à ce sujet, c'est intéressant de les poster. Je vais me renseigner de mon côté et j'en reparlerai ici si je trouve quelque chose.

À+

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

Hibou57 · Le 19/03/2011, à 15:08

À propos de Git vs Mercurial, un point en faveur de Git tout de même. Mais ce point peut-être couvert par Mercurial.

Je me demandais si les changements d'attributs et de droit d'accès peuvent être pris en compte par Mercurial (et les CVS en général, vu que je n'ai jamais pensé à tester SVN sur ce point, quand un temps je l'ai utilisé). Apparement, normalement non, et c'est justement le propos d'une extension spécifique de Git aux fichiers diff.

Maintenant, reste à savoir si cette extension de Git aux fichiers diff, peut prendre en compte tous les attributs, y compris les ACL et leurs attributs étendus.

Ce sera à vérifier pour plus tard.

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

Hibou57 · Le 19/03/2011, à 16:13

Voilà au sujet de Git, pour se renseigner, il faut chercher sur le Net à propos des "extended header" des diff de Git. J'aurais bien aimé en trouver une spécification officielle, mais je n'ai put trouver que la description de quelqu'un qui connait et qui a bien voulu prendre le temps d'en parler, dans un topic de StackOverflow :

How to work with diff representation in git

Le précédent lien a écrit :

The last line in extended diff header, which is
index f3e63d7..e8f44ba 100644
tell us about mode of given file (100644 means that it is ordinary file and not e.g. symlink, and that it doesn't have executable permission bit)

Ce qui n'est qu'un extrait, il en dit beaucoup plus.

Ça parle des droits classiques sous Linux. Et comme Git est apparemment réputé orienté POSIX, et comme les ACL n'ont jamais été standardisés sous POSIX (tout le monde se repose sur les brouillons de la norme, qui on tout de même été rendu publique, et chacun le fait à sa manière), j'ai un doute.

J'ai cherché s'il existait une variante de l'utilitaire diff autonome avec les même fonctionnalités, en dehors de Git, mais la commande git-diff, ne semble disponnible quand dans git-core, qui elle-même dépend de git. Donc pour utiliser ces diffs, il faut installer tout Git.

En tous cas, c'est intéressant cette extension. La suite, c'est de voir comment Mercurial se débrouille avec ça, puisqu'il semble en être capable.

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

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 17/03/2011, à 14:19

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

#2 Le 17/03/2011, à 14:39

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

#3 Le 17/03/2011, à 14:43

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

#4 Le 17/03/2011, à 15:00

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

#5 Le 17/03/2011, à 15:01

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

#6 Le 17/03/2011, à 15:03

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

#7 Le 17/03/2011, à 15:08

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

#8 Le 17/03/2011, à 15:11

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

#9 Le 17/03/2011, à 15:13

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

#10 Le 17/03/2011, à 15:20

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

#11 Le 17/03/2011, à 15:21

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

#12 Le 17/03/2011, à 17:26

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

#13 Le 17/03/2011, à 17:40

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

#14 Le 17/03/2011, à 17:53

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

#15 Le 17/03/2011, à 18:13

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

#16 Le 17/03/2011, à 19:59

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

#17 Le 18/03/2011, à 21:07

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

#18 Le 18/03/2011, à 22:11

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

#19 Le 19/03/2011, à 07:45

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

#20 Le 19/03/2011, à 08:47

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

#21 Le 19/03/2011, à 09:05

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

#22 Le 19/03/2011, à 09:39

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

#23 Le 19/03/2011, à 13:48

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

#24 Le 19/03/2011, à 15:08

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

#25 Le 19/03/2011, à 16:13

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

Pied de page des forums