Reprise du message précédent :
Putain les batailles de quotes, c'est pathétique

Exemple du partage entre devs: je suis avec un collègue sur un projet, on est sous SVN, il gère un "socle" sur lequel je me branche pour mon front web.
 
À un moment, j'avais un bug dont je n'arrivais pas à trouver la source (et qui pêtait l'appli), je voyais que ça venait du socle mais j'arrivais pas à trouver la source du problème dans le dit socle.
 
J'ai donc appelé mon collègue à l'aide. Problème, c'est un linuxien barbu et mon poste est sous windows, il y avait donc 3 possibilités:

• Qu'il viennent sur mon poste et se retrouve dans un environnement qui ne connaît et n'apprécie pas sans ses outils favoris, pas pratique
• Que je crée un fichier patch que je lui balance par mail avec mes modifs dedans, beurk, dangereux (il peut pas le committer, ou alors faut que je revert toutes les modifs chez moi sinon conflit massif des familles)
• Que je commit mes modifs instables pour qu'il puisse les récupérer.  

J'ai fini par faire le 3 parce qu'on est que 2 sur le projet, mais avec mercurial j'aurais pu commiter les changesets en local, faire un hg serve et il aurait simplement pullé de chez moi. Soit dans sa copie locale principale soit dans une autre copie créée spécialement à l'occasion (via hg clone)

Linus Torvald il préfère patcher à coup de tarballs qu'utiliser SVN, t'entends?
CVS done right is wrong, jeune pédé: Git c'est le content versionning à son meilleur.

moi ce que j'aime bien avec maskliin , c'est qu'il est toujours partant pout un troll sur le controle de version ou sur les langages exotiques  
 
et dans tous les cas, il finit toujours par penser que sa situation est LA situation et que donc ses solutions (qui sont généralement bonnes dans son contexte) sont LES solutions  
 
 
tu lui aprle de contexte mono utilisateur il t'amene la collaboration entre dev  
 
il te parle de bug critiques  qu'on decouvre 2 mois apres  
 
 
tu lui parles d'integration il te repond que la ligne de commande c'ets mieux et que de toute maniere, si tu ne veux pas faire de ligned e comamnde c'est bien fait pour toi  
 
bref, je ne sais pas lequel de nous deux troll le plus ( faudrai en faire un sondage )

 
ah ? on y arrivait bien pourtant...pourtant on était 5 à Lyon, et 2 en Pologne
 

un bon IDE le threade, donc ça devient une tache de fond...le temps que ça prend je m'en fou, je suis déjà en train de coder
 

heu, t pas obligé de publier toutes tes fichiers avec un CVS normal...si t'as modifié tata, toto et titi, tu peux très bien ne publier que tata.
 

comment ça gère les conflits ? parce que l'automerge, je me demandes ce que ça fait en cas de conflit dans le code...et de fait si il faut merger à la main je vois plus le gain, et tu retombe dans le risque de bordel : si A, B et C modifient du code qui va être mergé, y'a des chances que A, B et C modifient des portions identiques de code...et là tu multiplies le nombre de merge manuels à faire, et c'est à toi de gérer la priorité
mais sinon oui, c'est bien que ça y soit si ca couvre un besoin
 

 
je fais que répéter, je l'ai pas essayé moi même :  

et ça dit que ce repacking doit etre ordonné explicitement...
 

ça c pas exclus que pour des raisons de perfs t'aies du caching local
 

 
moi aussi : tu peux faire des hooks pré commit, commit et post commit, et idem sur la plupart des opérations...un peu comme une BDD avec des triggers...et c'est côté server que ça se passe
 

 
le pb étant que java aussi bien que .NET imposant de fait l'usage d'un IDE, ça devient un facteur pour un grand nombre de dev où l'usage d'un VCS s'impose...
 
après une bonne ligne de commande c'est sympathique aussi, on est bien d'accord...l'expérience m'a aussi montré que l'approche tortoise est super, en particulier pour des gens non informaticiens par essence (graphistes, etc...qui n'utilisent pas un IDE, et que la ligne de commande """"dos"""" rend fous)
 
 

T'as pas encore compris que lorsque masklinn dis quelque chose, c'est lui qui a raison, il faut toujours écouter ce que dis masklinn.
C'est pourtant pas compliquer à comprendre

Ouais mais dans ce cas tu peux pas commiter toto et titi

Si il y a un conflit il faut résoudre le conflit ce qui est normal, mais s'il n'y en a pas l'outil se démerde

Effectivement, ça c'est le problème de git (que mercurial n'a pas, ils stockent pas de la même manière, ça vient de l'implé de git)

C'est totalement vrai, et c'est un truc qu'ils sont en train de changer (je crois que ça a déjà été fait en head, mais pas encore dans une release officielle) pour que git repack automatiquement comme un grand

Les extensions dont je parle elle sont au niveau du client, pas du serveur justement, je parle pas du tout de triggers

 
attends , aujourd'hui c'est mon anniversaire
 
je peux bien m'offrir un petit troll en cadeau  

oh non, ça commence à devenir intéressant là

OK, je vois bien l'exemple, et j'admets sont utilité...mais poussons le raisonnement : tu as aussi un pb avec un composant fait par Roger, qui s'appuie en partie sur le socle de ton premier collègue (appelons le Tux, étant un linuxien), donc tu fais ta solution mercurial avec Roger. Roger a aussi un soucis avec le socle de Tux, et fait cette solution.
Et là tu te retrouves avec le bordel au moment de devoir merger "officiellement", parce que  personne peut merger du code qui tourne parce qu'il n'a pas moyen d'avoir accès à 100% du code fonctionnel (qqc la vision concernée, t'as tjs un merge qui dépend de code qui n'est pas accessible ni en local ni sur le repo public

Dans mon exemple, Tux doit merger 2 modifs en même temps, sans garanties qu'elles soient cohérentes, parce qu'il ne sait pas ce qui se passe entre Roger et toi...alors que si tlm merge son code chacun son tour, t'as tjs 2 personnes qui garantissent la cohérence

l'avantage du repo central et du commit séquentiel, c'est qu'au moment de merger, t'as tjs accès à l'état actuel du code, et que si l'update te renvoit rien, tu sais que si tu commit tu auras raison, et que ton commit forcera tlm à faire un update, donc à se synchro avec tes dernières modifs...

Roi Heenok  

en plus en argot anglais, git veut dire connard...ça s'invente pas

ouais et pis mercurial ça ressemble à mercury et ça veut dire pédé

ouais et puis maskliin ca ressemble rien

masklinn ça rime avec vaseline, vous pourrez pas dire que vous n'étiez pas prévenus

Donc à ce stade on va se retrouver avec les situations suivantes:

• Mon problème socle a été résolu par Tux, donc j'ai pu finir mon implé. Ma branche est fonctionnelle et stable
• Roger a résolu son problème, il a pu finir son implé, sa branche est fonctionnelle et stable
• Je push ma branche dans le repository central, on va dire que personne avait push depuis mon dernier pull donc pas de merge à faire
• Roger veut pusher, le repo lui dit qu'il y a des modifications distantes, donc il pull -u, ça met mes modifs dans sa copie locale, il crée une révision de merge (pour dire "ces deux chemins se rejoignent ici" ), il vérifie si il y a rien de pêté et il push
• Tux pulle le tout

Je vois pas où est le problème

Heuuu non...

Tu veux dire qu'il pull de mon tree puis qu'il pull de celui de roger et qu'il est censuite censé faire des modifs sur les 2 en même temps? C'est pas logique du tout, il est déjà en train de bosser sur mon problème donc il le résout, puis roger reviens par la suite

Edit: et en bonus il n'est pas obligé de n'avoir qu'une seule working copy chez lui, donc il peut puller de mon arbre dans une copie et de roger dans un autre

edit: ça sera ptet plus simple avec des jolis graphiques: http://betterexplained.com/article [...] lustrated/

 
ben Roger et toi avez bossé à partir d'un socle commun sur lequel vous avez fait des modifs chacun de votre coté. Rien ne garantit que ces modifs soient cohérente...dans ta séquence, toi t peinard, mais Roger peut se retrouver avec des parties significatives de son implémentation à revoir si ses modifs liées au code de Tux clashent avec les tiennes...parce qu'il aura basé tt sa branche sur du code "faux", et comme t'as pas commité tt de suite ni lui, y'a un effet tunel : ça pète plus tard, et potentiellement plus fort, parce qu'il a eu le temps de faire plus de trucs avant de se rendre compte qu'il est parti sur une mauvaise base...
 
au final il peut toujours faire son merge, mais il a le risque d'avoir bcp plus de boulot...parce que bcp plus de fichiers auront changé
 
multiplier les WC c'est retarder le pb : faudra bien les merger un jour, et plus t'attends, plus t'as de changements, et plus tu risques d'avoir des soucis dans ton merge...

si qqn pouvait prendre le relais ...
http://forum.hardware.fr/forum2.ph [...] 0#t1650287
 
Profil recherché : PHPiste patient

Dans ce cas là il y a un problème beaucoup plus profond que ce qu'un RCS peut ou doit gérer, puisque les demandes faites à Tux sont des fixes de bugs. Soit l'archi du code de tux est complètement fondue, soit le code de Roger reposent sur des comportements incorrects, mais dans tous les cas c'est pas le RCS qui en est la cause ou la solution.

Ben non, c'était une solution à ta déclaration que "personne ne va avoir du code stable", chaque WC est indépendante des autres et "stable" (tant qu'elle n'est pas pêtée instantanément, mais dans ce cas là elle n'a pas à être pushée), elles sont ensuite poussées séquentiellement dans le repo central et tout va très bien

 
Patéééééé

J'ai pas d'IDE , je fais comment?
 
Globalement, ça permet de :
 

• Commiter plus souvent.
• Avoir une copie locale versionnée, et tagguée correctement, IDE ou pas
• Avoir des points de retour indépendant d'un quelconque logiciel
• Publier uniquement du code qui marche, sans perdre les points de retour
• Optionnellement, créer un branche locale dans laquelle je commit du code pété/non finis/non testé

Si ton code est pété, je vois pas l'intéret de le publier, au non du dev partagé?
[*]

D'accord avec Masklinn sur ce point. Un RCS ne doit pas se substituer à un chef de projet. Si Roger et Tux bossent sur les mêmes parties de code, y a un pb de gestion de projet, pas de RCS
Quand j'ai commencé à bosser en mission chez un grand compte (en 2004) et que je leur ai vanté les mérites de CVS par rapport à PVCS et l'usage du mode optimiste (pas de locking sur les fichiers), ils m'ont tout de suite dit : "ouais mais les gens risquent de bosser sur les mêmes fichiers, alors qu'on n'a pas le problème si on lock". Ils ont fini par comprendre que c'était pas le rôle du RCS de gérer qui travaille sur quoi. Du coup j'ai pu progressivement mettre en place CVS à la place de PVCS et de VSS

et votre truc permet de commiter souvent soit, mais visiblement ça tend à faire publier moins souvent...et ça je pense pas que ce soit une bonne chose...

Quand tu commites, tu commites une nouvelle feature? Donc j'espère que tu commites du code qui fonctionne? Dans tout les cas, si tu commites en local, tu peux publier dans les même conditions, je vois pas le soucis

Pas nécessairement non plus, et c'est pas de ça que jubi parlait

Ca par contre oui, c'est exactement la même "cognitive dissonance" (et une variante du blub paradox ) qui se passe quand j'essaie d'expliquer les DVCS à des gens qui n'ont jamais utilisé autre chose que des CVCS
(le fait que je sois pas très bon prof aidant aussi)

Non. Ca fait simplement publier quand il est temps de publier (quand une tâche ou une fonctionalité est terminée, stable et testée) et ça permet de splitter une publication unique en un nombre illimité de commits, ce qui est très utile quand on implémente un truc un peu gros et un peu long.

 
vu sous cet angle OK...

http://zappatic.net/safarimicroformats/index.html

- Netbeans 6 a un plugins pour Mercurial
- Vous oubliez Perfoce

 
 
- sur pas mal d'aspects Netbeans est encore loin d'Idea ou Eclipse (je parle de la 5.5, j'ai pas testé la 6.0, ils ont pu faire des progrès sur l'éditeur de code)
- c'est super cher Perforce

Comme éclipse, mais je suis pas sur de la stabilité et de la qualité comparé à un plugin SVN (il y a aussi des interfaces graphiques et des tortoise-like en développement, si ça peut intéresser)

Ben non, c'est payant et c'est pas distribué.

Actuellement, il y a 5-6 SCM distribués majeurs/utilisables:

• Bitkeeper, qui est payant et cher et est globalement l'ancètre du truc
• Git
• Mercurial
• Darcs (extrèmement intéressant à tous les niveaux, mais avec une paire de bugs majeurs dans l'implé, apparement ils seront rêglés avec Darcs 2, mais pour le moment je conseillerais pas de l'utiliser, sauf si vous faites du haskell)
• Bazaar-ng (lent, par contre il y a Canonical qui le pousse. D'un autre côté il n'y a que canonical qui l'utilise)
• Monotone (lent, pas très utilisé, me semble que Taz est fan de celui là)

Et SVK, qui est relativement discutable (c'est un jeu de scripts Perl par dessus SVN, perso j'utiliserais plutôt git-svn ou hgsvn si je voulais utiliser un DVCS avec un repository central sous SVN).

Le reste est soit trop vieux, soit pas assez stable pour penser à l'utiliser soit complètement inutilisable tellement c'est compliqué (Arch )

tu vas me faire passer à Safari avec tes conneries

Si t'es sous FF y a ça : https://addons.mozilla.org/fr/firefox/addon/4106

Genre j'utilise FF sur mon mac, faut arrêter de rêver

Masklinn > Si tu n'utilises ni safari ni firefox t'utilise quel navigateur avec ton mac?

Camino, naturellement

Ah ouais, le truc qu'a 3 plug-ins dispos

On parle d'un navigateur pour surfer là je rappelle, et pour surfer sur un mac faut être suicidaire pour utiliser Firefox.

Mes collègues en sont contents, il a quoi de moins bien que la version pc ?

Il est lent et il est extrèmement moche (parce que l'interface ressemble en rien à une interface mac). Il reste intéressant pour le dev, mais il n'a strictement aucun intérêt pour la navigation.

oué, enfin de là à se suicider, hein...

Qui a dit ça? Je dis juste que FF sous OSX n'a aucun intérêt pour la navigation perso, il y a Camino pour Gecko et Safari pour Webkit