Reprise du message précédent :

symfony n'est pas un CMS c'est un framework de développement

C'est pourtant clair: SVN a l'avantage de s'intégrer avec à peu près n'importe quel IDE, et pour certaines personnes c'est un critère déterminant (typiquement sur le forum, nraynaud qui aura tendances à ne pas utiliser un outil de dev ne s'intégrant pas directement avec intellij)

Je t'ai déjà répondu

C'est vrai, on peut aussi utiliser VSS, après tout il est toujours sur un shared disk et c'est super bien les shared disks \o/

Mercurial | Git

Mais sinon oui

Ce n'est pas forcément dû au fait qu'ils n'ont pas le courage, mais tout simplement qu'ils n'ont pas besoin d'un IDE

Quand on fait du java, ne pas avoir d'IDE c'est pas une option.

Sympathique cette nouvelle lib de parsing de date : http://www.datejs.com/

 
Oui ok, je sentais que je confondais..
 
En gros avec symphony on fait n'importe quoi, alors qu'un CMS a plus une finalité precise (communautaire, site ecommerce, magazine, etc) ?
 
Bref c'un donc un framework solide que je cherche! Ya un gagnant? symphony?

zut, tu m'as devancé

 
ça me semble plutot un avantage, encore que c'est absolument pas indispensable : je me répète, y'a une ligne de commande très puissante, et TortoiseSVN, donc t'as l'embarras du choix quant à la méthode pour attaquer ton repository
 

pas explicitement anyway (je pense que tu devrais te relire, parce que t'as un style tout sauf explicite)
 

y dit qu'il voit pas le rapport
 

OK...à part le fait qu'il a une philosophie différente, je vois pas d'avantage souverain par rapport à SVN, si ce n'est que n'étant pas le standard, il a probablement une user base plus faible, moins de gens savent l'utiliser (meme si c'est pas un problème : ça s'apprend vite, et quand t'as compris la philosophie d'un SCM t'as compris en général)
 
et je condamne les raisonnements qui visent à dire : tout le monde l'utilise, donc c'est de la merde...je ne cautionne pas le moutonnage, mais parfois si tlm utilise qqc c'est qu'il y a une raison...

ben ici on commence a parler de bouger de CVS a Git, parce que les branching/merge c'est chiant, et qu'on bosse des fois offline.

Ce que je dis (pourtant relativement explicitement) c'est que SVN est très loin d'être le meilleur outil de gestion de révision, je conseillerais donc d'utiliser autre chose sauf dans deux cas: si la boite utilise déjà SVN (pour ne pas fragmenter la codebase) ou si l'intégration à l'IDE est un critère déterminant (parce que les alternatives que j'aurais tendance à préférer n'ont pas l'intégration IDE de SVN). C'est pourtant pas bien compliqué

Bien sûr que si, dans ce post je te conseille de relire mes posts précédents (ou même de les lire tout court, parce que j'ai du mal à croire que tu sois allé au delà du survol rapide) et à la fin de celui là je cite explicitement Mercurial et Git

Sauf qu'apparement t'as réussi à lire la partie 5mn mais t'as eu du mal avec tout le reste

D'ailleurs bizarrement ratibus n'a eu aucun problème à lire ça

Super, tu les a jamais essayé, tu sais pas comment ça fonctionne, mais ça t'empêche pas de dire que c'est naze \o/

J'ai déjà exprimé ce que je pensais de ce genre de déclarations, je vois pas l'intérêt de la ressortir.

Et alors?

J'ai aux dernières nouvelles jamais dit ça, t'as juste du mal à te faire à l'idée qu'il existe de meilleurs outils que ceux que ton chef t'a dit d'utiliser, mais c'est pas grave ça passera (ou pas)

 
What ?

je crois que les mots Mercurial (ou Git) ont été cité presque 12 fois chacun sur cette page, ça doit être un indice

 
Je suis en train de bosser sur un truc chiant, j'ai pas le temps de lire tout le topic, merciquand même

You've just been ratibused

Justifie toi...parce que la parole d'expert ex nihilo, ça va 5 min, mais bon, tu sors pas des masses d'arguments sur pourquoi c'est pas le meilleur

surtout le "très loin" attire ma curiosité

alors :
1) j'ai jamais dit que c'était naze, j'attends qu'on me démontre leur super avantage supérieur, là c toi qui interprète
2) de la part d'un mec qui décrète sans arrêt des trucs, me faire taxer d'arbitraire ça me fait doucement rigoler

J'ajoute que je me suis renseigné sur GIT, et à part le concept d'auto merging et toute la philosophie de merging qui a l'air super bien foutu (et que la vue Synchronize de n'importe quel IDE qui se respecte semble émuler de manière correcte), je suis plus sceptique sur le reste : ça a l'air bouffeur d'espace à moins de te taper une maintenance manuelle de ton repository, le mode distribué rend la publication du code en live moins commode, et dans sa description c'est surtout une évolution par rapport aux grosses lacunes de CVS, que SVN corrige déjà amplement

Ca a l'air très bien, de là à proclamer que c'est le truc le mieux, je pense que ça a le mérite de se discuter...

Oui, c'est pas pour autant parole d'évangile...je raccroche ça au raisonnement : "j'adorais l'artiste XXX, mais depuis qu'on est plus de 10 à l'écouter, c'est devenu une méga bouse commerciale"...

au hasard : support, taille de la communauté, probabilité de survie du bousin, employabilité de la compétence...que des trucs négligeables il est vrai  

tu l'as jamais dit, mais c'est un peu la contraposée de ton raisonnement ci-dessus : tu dénigres le concept d'utiliser le standard "for the sake of it" donc tu promeuts d'une certaine façon l'utilisation de trucs plus confidentiels

et j'adore ton ouverture d'esprit
1) masklinn émet une opinion
2a) XXXXX est d'accord et peut vivre en paix
2b) XXXXX n'est pas d'accord à 100%
==> XXXXX doit alors subir du bashing de merde, des arguments ad hominem foireux, jusqu'à ce qu'il quitte la discussion, ou se range à l'opinion de Masklinn

heureusement que tu fais que du dev, en politique tu serais un dictateur

par ailleurs je code plus, donc me chef me dit pas d'utiliser des outils...et quand je codais, j'étais plutot celui qui amenait les nouveaux frameworks, les nouveaux outils, donc bon

ben non ,parceque ma machine de dev est forcement un windows ( politique de la boite : toutes les machines persos sont  en windows XP ) et que jen 'aurai pas un environnement similaire a une machine en prod, surtout au niveau de l'accès
 
 
a noter ,que l'equipe de développement, c'est moi + moi  et que l'equipe de validation c'est moi + le colonel  quand il a le temps , et que le client, c'est de l'interne  
 

 
peut etre parceque tu as toujorus bosser dans de "grosses" structures
 
quand tu es le seul a bosser sur un projet tu t'aperçois que SVN devient juste une sauvegarde a peine améliorée. Donc c'est un plus , mais ce n'est pas obligatoire. Le prévu pour bientôt c'est tout simplement que je vais avoir un stagiare et que, vu qu'on sera 2 a bosser sur le même projet, le versionning et la resolution des confilts de merge deviendra important
 

Ah moi c'est surtout le concept de branches qui m'a intéressé. Pouvoir s'amuser à tout casser sur une copie du source, sans avoir à faire un vieux copié/coller à l'arrache. Et pouvoir merger par après si tout est ok. D'ailleurs mon repo SVN est en local, je fais rien à distance.

Wah tout copain sur le contexte sauf sur SVN que j'ai même pas encore eu le temps d'essayer  

C'est un peu plus que ça qd meme
Perso je travaille seul sur mon projet actuel et SVN c'est quand même bien pratique. Tu peux remonter l'historique proprement et rapidement, faire des diffs entre différentes versions rapidement... Rien que pour la gestion de l'historique (pour un travail en solo) ça vaut le coup d'y passer.

Moi je cherche un truc qui fasse automatiquement la copie des fichiers modifiés en dev vers la prod, ça fait ça SVN ? Pour l'instant c'est une arborescence papier, des ronds rouges et des traits noirs (et un client FTP)

Un process de build propre + le deploiement avec du rsync rulezz

Tu peux faire un script post-commit par exemple, mais n'est-ce pas un peu dangereux ?

Rien capté à part "propre" et "rulezz"

Ca dépend ce que ça veut dire

 
c'est clair que ca vaut le cout d'y passer, mais c'est moins nécessaire que ca ne l'est quand il y a plusieurs personnes qui bossent sur un même projet
La en cas de soucis, je dois remonter des sauvegarde, ce qui ets un peu long .  
 

 
c'est ce que je fais avec mon pauvre script rsync
en plus ca ne copie que les modif et ca tourne super vite

siouper, et si tu veux revenir a une version precedente, tu fais comment?

 
Non, en vrai comme il a un physique ingrat, il se prendrait un putsch des militaires en moins de deux semaines
 

Google me dit que rsync ressemble à ce que je veux, seul problème : j'ai des fichiers en dev dont je ne veux pas qu'ils soient copiés en prod (configuration, scripts de debugage, fichiers non utilisés)...

Après y a sûrement une option pour ne créer aucun fichier dans la destination ?
Pour la config ya ptet moyen de le mettre ailleurs...

Je savais pas que tous les dictateurs avaient la même gueule que Brad Pitt.

il gere aussi des listes d'exclusion
 

cool, et cf edit, ya moyen de le forcer à ne créer aucun fichier ?

Avantages de Mercurial (ou Git) sur SVN:

• Gestion des conflits plus rapide et plus efficace, à tendance à trouver moins de conflits et à ne les trouver que quand il y en a réellement
• Track les merges tout seul (donc pas besoin de noter la dernière révision mergée de A dans B, et on peut facilement merger dans les deux sens)
• Et quand on merge 2 branches (ou 2 copies locales puisque dans un DVCS une copie locale est une branche anonyme) on garde toutes les révisions des deux branches et on ajoute juste une "merge revision" qui ne fait que dire "ici on joint les deux branches pour n'en laisser qu'une seul" (s'il n'y a pas de conflits naturellement, sinon on résout les conflits et la merge rev est un peu plus consistantes). On évite donc la perte totale d'historique caractéristique de SVN.
• La quasi totalité des opérations sont locales: status, log, update, revert, annotate, commit, ... Les seules opérations distantes (qui vont taper sur le serveur) ce sont push et pull => pas de délai réseau, au final c'est beaucoup plus rapide d'utilisation et beaucoup plus agréable.
• un commit est local, il n'est pas publié instantanément à tout le monde, donc il est parfaitement possible de commiter des trucs non fonctionnels ou partiellement fonctionnel pour garder une marque de l'endroit où on est, ou parce qu'on se prépare à faire un truc risky, ou autre... sans pêter le build global ou emmerder les autres devs
• Il est parfaitement possible à des devs de partager leurs copies locales l'un avec l'autre, ou même juste certaines révisions, ou de se créer un arbre à eux sans avoir à passer par une branche publique sur le repo central (ou même pire, le trunk). Ca facilite donc la collaboration entre les gens au sein des sous-projets ou modules. C'est d'ailleurs très utilisé dans le dev du kernel linux (quand deux sous-systèmes ont besoin de bosser ensemble mais ne veulent pas publier des modifs instables dans les arbres officiels, ils se créent des repository "de travail" semi-privés pendant ce temps)
• Bizarrement, bien que beaucoup plus d'infos soient conservés (intégralité de l'historique et autres) une copie locale Mercurial ou Git (qui est en fait un repository complet) est souvent de la même taille qu'une copie locale svn, voir plus petite.
• Ils sont pluggables (Mercurial en Python, Git aucune idée) donc si on a envie/besoin d'étendre l'outil (ajouter des commandes ou autres) on peut le faire relativement facilement, genre ajouter des trucs comme "bisect" (outil de recherche par bisection ) ou "quilt"

je sais pas si j'en ai pas oublié par rapport à http://forum.hardware.fr/forum2.ph [...] 0#t1647847 et j'ai pas le courage de differ.
 
Si tu finis par être intéressé, je te conseille aussi de regarder http://video.google.com/videoplay? [...] 1317502612 et http://www.youtube.com/watch?v=4XpnKHJAok8
 

Dans l'ordre:

• Non
• Ca en bouffe moins que subersion
• Blague?
• Ca va beaucoup plus loin que de simples évolutions par rapport à CVS

Au moins on est d'accord là dessus

De l'accès à quoi?

non, j'utilise un RCS sur tous les projets y compris perso

Pas d'accord, c'est aussi

• Une conservation de l'historique complet et des évolutions du projet petit à petit en relativement fine-grained
• Une manière de centraliser et faciliter les backups
• Une manière de synchroniser les machines quand on peut (ou doit) bosser de diverses machines différentes, ce que je fais souvent sur mes projets perso (je bosse à la fois sur mon PC "desktop" et sur mon mac)
• Ou quand on a plusieurs environnements différents (dev, recette, prod, ...)
• Si dans le futur un dev supplémentaires arrivent ou tu laisses le projet à quelqu'un d'autre il pourra le reprendre dans de meilleures conditions que "attends je t'envoie les sources par mail de ma machine", idem si tu quittes la boite en fait, ou si tu as un accident et que tu peux plus bosser, ou...

En bonus en termes de dev, si tu trouves un bug tu peux "facilement" trouver quand il a été introduit, à quelle occasion et dans quel contexte (via une recherche par bisection), si tu te rends compte qu'un truc est pêté il est trivial de revenir en arrière à une version qui fonctionne (ce qui peut être intéressant quand tu viens de déployer un truc avec un bug critique en prod), et ça facilite le forking si tu dois gérer un 2e projet quasi identique ave des petites spécialisations

Ben on est pas d'accord du tout là dessus

Non, par contre ça le facilite puisque tu peux la faire en une seule commande (SSH dans le serveur non compris)

Un peu oui

Donc oui en fait ?

Ben non, automatique c'est automatique, une commande c'est du manuel facile mais c'est quand même du manuel (je préfère quand c'est emilio de la rosa personnellement)

de l'acces au données du CMS , de l'acces aux autres serveurs, aux services installés  
par exemple le serveur web heberge en local le moteur de recherche ( solr ) avec une interface sécurisée pour y acceder ( interface qui ajoute , entre autre les droits utilsiateurs ) . Pour eviter que l'interface ne soit court circuitée, la paramétrage réseau est tel qu'il n'est pas possible d'acceder au moteur de recherche si on est pas sur la machine locale.
Ma machine de dev n'est pas assez robuste pour pouvoir heberger ca ( indice : la ligne de commande qui me permet de lancer solr est java -Xmx1024M -jar start.jar )  
 
 
Donc je ne PEUX PAS avoir en local l'equivalent du serveur de prod ou du serevr de test
 

et moi je porte un caleçon noir. Est ce que ca te convainc de ma supériorité ?  

pour le fine grained ( la journée, l'heure ) , n'importe quel IDE permet de revenir en arrière, meme si je te l'accorde , c'est plus facile de taper des lignes de commande spour faire 2 Ctrl Z
 

une machine de prod, une machine de dev, 3 scripts rsync ( temps de mise en place : 15 min )  

c'est pour ca que je ne bosse pas en local , quand je e connecte de chez moi via vpn, je n'ai pas de synchro a faire , j'ai juste a avoir un IDE  

J'ai  
 
mais pour de la mise en prod, rsync fait le boulot efficacement dans 99.7% des cas . Et dans les 0.3% il me suffit de copier les fichiers voulu.
Avec une  arborescence claire, et vu que je bosse seul dessus, ca pose peu de pb  

surtout que j'ai dis que je ne bossais jamais en local, et que toutes les sources sont sur le serveur , et que l'arrivé d'un SVN/mercurial etait prévu avant l'arrivée d'un stagiaire
 
mais j'ai parfois l'impression que tu ne lis que ce qui t'interesse dans mes reponses  

Quand tu as trouvé exactement quel ligne de code provoquais le bug, il est souvent aussi trivial de corriger le bug que de revenir en arrière
 
le truc long avec la recherche d'un bug, c'est de voir la cause.
 
Mais c'est vrai qu'avec mercurial , il me suffit de remonter  les 217 révisions précédentes et de regarder si elles ont le meme bug, puis de faire des gros diff , et enfin de commencer a me dire " tiens si je cherchais a corriger  le bug plutot qu'a voir qui l'a introduit"

Ah ben non, c'est de l'automatique après avoir appuyé sur le bouton
Fin bref c'est ça que je veux, sinon ça me sert à rien d'avoir 2 serveurs si la copie doit se faire sans mon accord

N'importe quel IDE te permet de revenir 2 mois en arrière à l'heure près? Tu dois avoir des IDEs vachement plus violents que moi.

Mais tu paies ça par de gros délais dus au réseau

Jusque au moment où tu bosses plus tout seul, ou bien au moment où tu t'en vas.

Ce que je dis c'est que si ça avait été fait à l'origine il n'y aurait aucun boulot à faire à ce niveau là.

Ca dépend du bug, et savoir d'où le bug vient et quel est le contexte de son introduction ça permet souvent de mieux comprendre pourquoi il est là, ou de ne pas pêter le truc en tentant de le corriger

Fail 1. Tu n'as pas à "remonter 217 révisions", tu prends une révision que tu sais fonctionnelle, puis tu fais une recherche par bisection entre les deux, il y a même des extensions spécialement faites pour ça et au final ça ne prend souvent que quelques minutes pour trouver quand ça a été introduit.

De quoi tu parles?

Où j'ai parlé de "voir qui l'a introduit"?

Dites, au lieu de créer du html via javascript, est-ce qu'il ne vaut mieux pas avoir les éléments à cloner DANS le html (dans une section cachée par ex, une sorte de lib de la page ) ?
C'est crade mais je trouve ça toujours moins crade que de créer du html via js

 
bref, c'est intéressant, mais je vois pas ce qui permet de dire que c'est TRES LARGEMENT supérieur à SVN...c'est une autre philosophie de boulot, mais pour ce que je fais encore (pour mon usage hein, j'ai pas de volonté hégémonique), j'y vois plusieurs inconvénients :  
- intégration dans les IDE Java pas forcément au point (y semble y ait un plugin eclipse, c'est moche à l'heure où SVN a un support quasi intégré dans Eclipse, je parle pas d'IDEA et autre)
- ne faisant plus partie d'équipe de dev distribuées, j'ai pas de soucis de perfs qui justifieraient l'approche "locale" des SCM distribués
- réapprendre un autre outil et changer mon environnement pour un gain très marginal (if any) me semble pas justifié...
 

J'ai jamais réussi à faire un truc comme ça, à chaque fois c'est la merde noire les merges CVS/SVN

Quand on commence à utiliser un DVCS, la différence devient flagrante. On passe de 3-4s pour un commit (sur un lan) a <1s

Bof. T'as pas en permanence envie de tout publier, il peut y avoir des trucs qui sont en cours de boulot, des tâches assez lourdes dont le résultat intermédiaire est instable/pas testé et que tu voudrais sauver sans devoir le publier.

Sans compter que rien ne t'empêche de tout publier à chaque fois. la différence c'est qu'un DVCS te donne le choix.

Ben non, justement parce que tu ne te soucies pas de ce qui a déjà été mergé ou pas, ça n'a pas d'importance parce que c'est l'outil qui le gère.

edit: Et note que c'est une possibilité qui est là si tu en as besoin, pas un truc impératif. Je met un post après ça pour un exemple où ça m'aurait été utile.

Je peux voir où? Parce que je vois rien qui y ressemble sur http://en.wikipedia.org/wiki/Git_%28software%29

D'après mon expérience et à peu près tous les rapports sur des switch SVN -> Mercurial ou SVN -> Git que j'ai pu voir, le résultat est à chaque fois que la working copy mercurial/git fait entre 70 et 120% d'une WC SVN (grosso merdo)

C'est bien pour ça que je l'ai noté en gros avantage des DVCS, parce que ça semble illogique alors que dans les faits c'est le cas (la WC SVN doit explicitement conserver diverses informations bien lourdes pour pouvoir faire les revert ou status en local)

Dans le serveur, je parle pas du serveur je parle d'étendre le client via plugins

J'ai déjà dit que c'était un point avec lequel je ne suis pas d'accord mais qui peut être extrèmement important (et même bloquant) pour certaines personnes

Putain les batailles de quotes, c'est pathétique