Bonjour,
 
Pour un petit projet C++ où nous sommes 2 à coder, je compte utiliser WinCVS, qui sera bien suffisant pour ce que nous avons à faire. Mais j'aimerais avoir un outil graphique pour la résolution des conflits au merge, comme celui intégré à IntelliJ IDEA que j'utilise pour Java (on voit les 2 versions du fichier en parallèle et on accepte/rejette les modifs une par une, la version mergée étant mise à jour dynamiquement). Quelqu'un connaît-il un outil gratuit sous Windows qui ferait ça ? Pas Eclipse svp, je n'ai pas envie d'installer un marteau pour écraser une mouche. Merci !

Ben tu peux linker winmerge à wincvs / tortoisecvs etc.
C'est ça que tu veux ?

 
Ah ben peut-être ! Connaissais pas winmerge, je vais voir s'il fait l'affaire. Merci.
 

J'utilise KDiff. Un point de vue sur les différentes offres gratuites? i.e. KDiff/winmerge/autre...

utilise monotone

 
Tiens donc, je ne connaissais pas non plus. Ce serait un projet perso j'aurais testé avec grand plaisir, mais au boulot j'aurais du mal à justifier l'utilisation d'un outil "slightly unorthodox" (je cite le manuel) en version 0.34. Je lirais la doc quand même, voir ce qu'il a de différent de CVS/Subversion.
 
Edit : je réponds au cas où tu t'adressais à moi, Taz.

le truc c'est que monotone ne nécessite ni serveur ni rien. et qu'il a des algorithmes de fusion évolués qui font qu'on a bien plus rarement des problèmes. évitez les conflits, c'est important.

 
Alors là tu m'intéresses beaucoup. Après une petite dizaine de minutes passées dans la doc, j'ai l'impression que ce truc est génial. Bon, j'encadre déjà une personne débutante donc je ne vais pas ajouter de l'incertitude à ce projet, mais merci de l'info je regarderais de très près dans quelques temps.  

 
+1
 
Ce qui m'intéresse surtout, c'est l'absence totale de serveur (accès aux dépôt via HTTP/FTP), ce qui a l'air d'être rendu possible par monotone-dumb. Quelqu'un a plus d'infos à ce sujet ?

bah tu suis le tutoriel de monotone, et là tu vois que tu peux bosser seul sur ton poste avec juste monotone et un fichier db qui stocke le tout.

Monotone s'nul, mercurial et darcs sont mieux

J'ai de gros pb avec TortoiseCVS. Il bute très souvent sur des opérations de commit ou d'update sans raison, là où SmartCVS, par ex., fonctionne sans poser de difficultés. C'est dommage parce que sinon, j'aime bien cet outil.
Mais bon, comme dit plus haut, CVS, c'est un peu l'ancêtre de la gestion de conf. Il y a quand même mieux sur le marché, ne serait-ce que SVN. Mais tjrs pas terrible au niveau du merge.
Et centralisé.

Enfin, en ce qui concerne les "nouveaux venus" du libre, j'ai fait ma petite revue de presse. Voici des avis informés (qui valent ce qu'ils valent):
http://www.ligarto.org/rdiaz/RevisionControlBkmk.html
Il en ressort que 3 systèmes sortent du lot: Bazaar-NG, darcs et Mercurial.
Au moins deux projets de taille respectable, - plusieurs dizaines de milliers de fichiers avec un historique conséquent -, ont étudié ces produits, et pour des raisons de performances, ont choisi Mercurial: OpenSolaris et tout récemment Mozilla.

Pour cette raison, les devs de Bazaar se concentrent aujourd'hui sur l'amélioration des performances. Actuellement, ce dernier souffre de grosses lenteurs au-dela de ~10 000 fichiers.

darcs est aujourd'hui capable de gérer quelques milliers de fichiers grand maximum, mais déjà pas rapide, il souffre de réels problèmes de performance sur les gros fichiers et les conflits importants (algorithme de merging exponentiel).
Mais il semblerait que ce soit celui qui gère le mieux les merges, Mercurial suit de peu. Vu leur mode de fonctionnement, ils sont sans doute au moins aussi performants sur ce point que Clearcase, dont la qualité du merge avec historique est le principal point fort.

Mercurial et git semblent aussi très rapides en comparaison de CVS/SVN (et je ne parle même pas de Clearcase).

Un avis récent de la part d'un hacker: http://changelog.complete.org/cate [...] rogramming
http://changelog.complete.org/post [...] buted.html

Hop une vidéo de présentation de mercurial chez Google (en anglais): http://video.google.com/videoplay? [...] 1317502612
Cze topic devrait être déplacé.

 
Certes je suis plus SVN. J'ai pas remis en cause le choix de cvs parce que ce n'était pas la question du topic.

Je teste Mercurial en ce moment au bureau, sur un repository perso, avec un projet de taille moyenne (9000 fichiers, ~160 Mo). Je peux sauvegarder des versions intermédiaires de mes devs sans les commiter dans le repository officiel (CVS).

Pour l'instant, ça a l'air très bien foutu et complet, pas de mauvaise surprise. La prise en main est quasi instantanée:
1. installer Python
2. installer Mercurial
3. créer un fichier mercurial.ini dans son répertoire home qui donne son nom d'utilisateur et son adresse email
4. aller dans le répertoire à mettre en conf (disons, "superprojet" ) et créer un fichier .hgignore qui décrit les types de fichier que le système doit ignorer
5. Tester:

donne la liste des fichiers à mettre en conf. Adapter le .hgignore en conséquence.
Une fois que c'est bon, taper:

Et voila. Mercurial crée le repository dans le répertoire .hg.
Si on a fait une erreur avant le hg commit, on peut taper hg remove (pour enlever des fichiers/répertoires de la liste à mettre en conf) ou hg rollback (annule la dernière commande).
Après, ça roule. M'enfin ça ne fait que 3 jours que je l'essaye. Je n'ai pas encore testé la fonctionnalité de merge. S'il fonctionne aussi bien que ce à quoi on peut attendre d'un outil gardant l'historique des merges, et si ces premières impressions se confirment, alors il se pourrait bien que Mercurial puisse remplacer ClearCase sans problème. Si j'en crois la documentation en ligne des commandes, il est capable de faire tout ce que fait CC à la fois plus simplement (la syntaxe des commandes CC me donne des boutons) et plus rapidement. Ne manque plus qu'une GUI.

euh pareil en monotone sauf que y a moins de truc à installer ...

http://weblogs.mozillazine.org/pre [...] tou_1.html

Les principes sont les mêmes (le modèle de mercurial est inspiré de celui de monotone), mais le support multiplateforme est meilleur, et les triggers sont écrits en python

Edit: accessoirement
http://pablotron.org/?cid=1524

La lenteur c'est vrai sur les pull initiaux, mais c'est tout. Sur ma ligne DSL 1024, je pull les 60Meg de monotone en 30minutes. En local, ça va beaucoup plus vite. Ce qui est lent c'est la vérification des révisions : beaucoup de révisions, beaucoup de travail. mtn met l'accent sur la sécurité. et il y a de constant progres. J'utilise tous les jours, sur des bases plus ou moins grosse (1 <-> 200Meg) et c'est instantané.
 
Et pour les certificats, c'est des RSA gérable et reconnu par ssh agent.

et pour le multiplateforme :
- sur quelle plateforme hg est il présent et pas mtn ?
- les hooks de mtn sont en lua donc tout aussi portable.
 
Donc argumentation nulle sur le multiplateforme.

Putain mais apprends à lire, j'ai pas dit que monotone n'était pas multiplateforme j'ai dit que le support du multiplateforme mercurial était meilleur, notamment parce qu'il est aussi rapide sous Windows que sous les autres plateformes, ce qui n'est pas le cas de monotone

voir au dessus, ma mention de python n'est en aucun cas faite dans le cadre de la portabilité du logiciel

pourquoi ça serait plus lent sous windows ou un autre ?

j'en ai aucune idée, j'énonce juste un fait: toutes les évaluations de monotone ayant inclus windows (sans aucune exception) ont clairement mentionné la lenteur excécrable du logiciel sur cette plateforme
 
Après pourquoi c'est lent je dois te dire que je m'en contrefous, et ne faisant pas partie des devs de monotone tout ce que je peux t'en dire c'est que je ne suis pas la cause de la lenteur de monotone sous Win32

euh j'utilise monotone sous windows et je ne constate aucune lenteur. Maintenant si un benchmark d'import de 40G dit le contraire, OSEF.

Je n'ai personnellement jamais eu de problèmes avec darcs, ça ne l'empêche malheureusement pas d'avoir de gros bugs (2). Je crains que tes circonstances personnelles n'aient pas grand intérêt face aux problèmes potentiels de monotone que mercurial n'a pas.
 
En bref, monotone présente un risque (de lenteur notable dans le traitement de diverses opérations) que mercurial n'a pas, et monotone ne me semble pas avoir le moindre avantage fondamental sur mercurial, donc ça n'a pas réellement de sens de conseiller monotone plutôt que mercurial

bonjour le FUD ...
 
mercurial présente un risque de lenteur parce qu'il est écrit en python.

C'est pas du fud putain, les problèmes de lenteur de monotone ont été observés par de multiples personnes et projets, à ce stade là on appelle ça des faits, pas du fud

Et de l'autre côté, mercurial n'a aucun problème de lenteur et la rapidité est l'une des cibles importantes des devs

il te suffit de prendre la ML de ce mois ci de monotone pour y lire que les développeurs ne sont au courant d'aucune lenteur spécifique à windows.
 
et je répète : la lenteur, c'est sur un pull initial volumineux. Et pas un truc du genre "40s pour faire un commit" ...

alors que monotone met l'accent sur l'intégrité des données. Attention aux pertes de données avec Hg.

et je répète: mercurial n'a aucun cas de lenteur répertorié

et strictement aucun cas de corruption de données non plus, pour un RCS ça se verrait et répandrait très très vite, surtout vu les utilisateurs de Mercurial (OpenSolaris, Xen, e2fsprogs, la team ACPI d'intel, ...)

http://alienghic.livejournal.com/tag/mercurial
 
7j de conversion pour le CVS de mozilla, t'appelle ça comme tu veux.

(et en passant, monotone est plus facile à installer sous windows, et y a des tas binaires statiques pour des tas de systèmes ce qui fait que c'est très facile à transporter ou installer à droite et à gauche)

J'appelle ça le CVS de Mozilla, c'est l'un des repo les plus gros et complexes (en terme de branches et de tags) qu'on puisse trouver

Maintenant si tu as les chiffres pour la même chose sous Monotone je les veux bien hein

Pardon?

Monotone: un installeur contenant les binaires Windows, pas de dépendances externes
Mercurial: un installeur contenant la distro Windows, pas de dépendances externes

Les installeurs sont de tailles équivalentes (2.80Mo pour Mercurial 0.9.3, 3.14Mo pour Monotone 0.34) et de fonctionalités équivalentes (ajout des binaires au path, visualisation de documentation), les répertoires finaux sont du même ordre de grandeur (7.4Mo pour Mercurial, 11.8Mo pour Monotone)

C'est exactement pareil pour mercurial hein (enfin non la seule différence c'est qu'il n'y a pas de package linké statiquement en linux/glibc, mais il y a des packages d'installation pour beaucoup plus de plateformes, et la méthode d'installation depuis le source est la méthode standard Python)

ste dialogue de sourds

Stoi sourd pov' phenos  

Ce qui n'est pas comparable puisque monotone c'est un seul binaire.
 
(et de mes derniers tests personnels entre l'import cvs interne de monotone vs. cvs2hg, mtn était 35x plus rapide.)
 
Fin.
 

Oui mais ton exemple montre que mercurial est le gestionnaire de conf choisi par les filles.  
 
Et puis ça suffit, les entubages de mouches. C'est pas sur les 10 mn que dure l'installation qu'on va déterminer son choix.

 
Oui, mais ce qui m'intéresse, c'est que le fichier db soit disponible par FTP/HTTP sur un serveur centralisé (genre je veux bosser depuis plusieurs postes, mais je n'ai pas de dédié sous la main pour faire tourner un serveur mtn, alors je me contente d'un hébergement web...)
 
 
PS: désolé pour le délai de réponse : j'étais pas là la semaine dernière

Les outils décentralisés n'empêchent pas que l'un des postes serve de serveur central, c'est même nécessaire pour faire un backup et pour que tout  le monde puisse se mettre à jour.