Discussion :

[martopioche]

Aïe... Non, ce ne sont pas les même notions (mais venant d'un utilisateur de Clearcase ça ne m'étonne pas )

Eclipse, notamment, permet de gérer au niveau local ce besoin de version de sources.

Faux, Eclipse gère des versions de fichiers, pas de sources. Une version de sources est l'état de l'ensemble de tes fichiers (pour SVN, Git, Mercurial, Baraar...). Comment peut tu restaurer l'état de tes sources à la modification n donnée d'un fichier avec l'outil d'Eclipse ?

Le but d'un outil de version logiciel, c'est de sauvegarder les réelles nouvelles versions : correction d'un bug, évolution, nouvelle fonction, etc.

Oui et non. Pour cela, il y a les tags et les liens vers les versions spécifiques dans les outils de suivi de tickets.

Ce principe ne peut pas s'appliquer dans un projet avec 25 développeurs sur une MC (maintenance corrective) + 3 projets d'évolution successifs conséquents en relation avec d'autres évolutions de logiciels connectés en //

Au contraire, un exemple de théorie : http://martinfowler.com/bliki/FeatureBranch.html

Pour le reste, tu confond version de sources (qui trouve sa place dans un gestionnaire de sources) et version logicielle (qui est le tag d'une livraison). Sans ajouter la caricature du projet OpenSource ( = non structuré). Sans prôner la multiplication des versions à outrance, versionner souvent permet d'isoler les modification. Si tu dois versionner uniquement l'ensemble du travail fini, tu a plus de chance d'introduire, d'amplifier, et de rendre difficilement identifiable un "bug" (je veux rester générique).

La gestion de conf, j'en bouffe depuis 5+ ans maintenant et je réalise maintenant comme un développeur n'y connait rien au début ...

On ne va pas se les comparer, mais je rajouterai que beaucoup de développeurs n'y comprennent rien tout court. Pas la peine d'être au début ou plus loin. Pour la plupart, gérer une version consiste à exécuter un update/commit en priant qu'il n'y ai pas de merge. Le sens derrière...

[Alpha573]

J'ai du utiliser Subversion pendant 4 mois pour des projets à la Fac.
Je n'avais pas d'expérience dans Subversion ni aucun autre gestionnaire de sources.
J'en suis plutôt satisfait mais il vrai que les opérations de déplacement de fichiers sont parfois fastidieuses. Mais le gros problème reste le fait, que, comme souligné dans l'article, le commit est sensible aux défaillances du réseau.
Si on a un gros commit à faire, il n'y a pas de mécanisme de transaction et on se retrouve avec un joyeux foutoir sur le dépôt.
Cependant j'en reste assez satisfait.

[Legion.nux]

Perso niveau pro... on est passé de Cvs à Svn... le changement a déjà été douloureux pour certains... habitudes tout ça... Cependant, finalement assez deçu par Svn... bien plus véloce c'est certain mais plus-value pas fantastique et surtout merges assez douloureux...
Les plugins eclipse ne sont pas si merveilleux que cela voir même assez lourdingues (démarrage eclipse, ...)

Niveau perso j'ai essayé quelques dvcs... première expérience avec Bazaar que je trouvais déjà pas mal, même si un peu fouillis sur certaines fonctionnalités (repo central,...), puis je suis passé à Git et c'est vrai qu'une fois la phase d'apprentissage passée... il fait vite oublier Svn. J'aimerais bien qu'il soit adopté niveau pro mais bon déjà vu le temps qu'il a fallu pour passer de Cvs à Svn... c'est pas demain la veille.

Après les goûts et les couleurs c'est l'affaire de chacun... mais bon les DVCS permettent de nouveaux comportements, notamment dans le dev collaboratifs (github, bitbucket, ...) et au final ça en devient presque plaisant...

c'est plus vos commentaires de "svn c'est nul, Git c'est trop bien" sans démonstration sur un projet réel qui me gêne.

heu un noyau Linux par exemple, ça fait assez réel ??
Je taquine

[Aéris22]

Ce qui manque énormément à SVN, c'est très clairement la notion bien distinct de commit / publication qu'apportent les DSCM*comme Git et Mercurial.

J'ai au moins 2 ou 3 cas bien concrets d'application où je ne pourrais plus me passer de telles fonctionnalités.

* Développement sans serveur disponible

Obligation d'utiliser du bon vieux CP-OLD, impossible d'obtenir une autre révision que celle sur le poste (par exemple de visualiser une branche en cours de dev), d'effectuer plusieurs commit bien distincts (tout sera commiter avec le message «Trajet Paris-Brest» une fois revenu au bureau)

Avec SVN, impossible de travailler dans le train durant un déplacement pro avec 4h de trajet.
Impossible aussi de commiter des correctifs effectués lors d'une réunion avec le client (méthodes agiles exclues d'office!) voire de réaliser un tag pour une livraison si on n'est pas au bureau.

Cas plus atypique, le travail à la maison! Avec SVN*et sans VPN, mission impossible.

* Modifications multiples ayant du sens globalement mais pas atomiquement

J'ai plusieurs exemples où il est intéressant d'avoir la distinction commit / push.

Le cas de la correction de bugs où je sépare généralement la correction proprement dite du rétablissement des tests unitaires (qui peut prendre plusieurs heures), afin de pouvoir faire une revue de code efficace sans être pollué par des diff de reprise de test. Ceci permet aussi de pousser le bugfix chez les autres devs qui en ont besoin rapidement sans attendre les tests U qui arriveront le lendemain (merci les DSCM!) sans pour autant plomber l'intégration continue (pour l'ensemble des autres devs et jusqu'au lendemain…).
C'est uniquement quand le couple code + test U est opérationnel que je pousse le tout sur le serveur central pour donner à manger à la CI.

Autre cas à la con avec SVN (qui a déjà été mentionné ici), je dev un bugfix, je remet d'équerre les tests. Tout marche chez moi, mais quelqu'un a fait un commit entre temps sur le dépôt.
Version avec SVN, je veux commiter je ne peux pas, il faut que j'update et que je mélange du merge avec du commit de bugfix sous peine de casser la CI. Aucun traçabilité, tout est mixé (code métier, code test, code merge), pour revert le bugfix sans perdre le merge, c'est mission impossible.
Pire, le merge pourrait faire l'objet d'une branche à part entière pour restaurer l'application, mais il sera trop tard après le update, tout sera déjà mixé et pas de commit du bugfix…
Version DSCM, je fais 2 commit (code + tests U), j'update, je merge et je commit, puis je pousse le tout. 3 commits, simple à tracer et sans mélange d'objectifs sans rapport entre-eux. Niveau traçabilité il n'y a pas mieux.

* Intégration et revue de code

Comment mettre en place du filtrage efficace par revue de code avec SVN? Impossible, le développeur devra commiter dans le dépôt public pour demander une relecture et son code est accepté *a priori*. Si le code est rejeté, le mal est déjà fait, tout est déjà updaté sur tous les postes de dev et tout le monde va se manger un revert et un merge…
Et avec le grave problème du merge de SVN, impossible d'envisager des branches pour chaque relecture!
Alors qu'avec un DSCM, il envoi son code dans le dépôt d'intégration du release manager, qui l'acceptera ou pas dans le dépôt public (read-only!). L'acceptation est *a posteriori* et un rejet ne pénalise personne!

[gagaches]

Aïe... Non, ce ne sont pas les même notions (mais venant d'un utilisateur de Clearcase ça ne m'étonne pas )

Gestionnaire de conf clearcase stp :p

Effectivement, à force d'avoir des outils hyper rigides et structurés, ma pensée se rigidifie.
Rien que pour les derniers commentaires, je suis content d'avoir discuté sur ce sujet ici (j'ouvre ma vision et je vois d'autres approches différentes).

Faux, Eclipse gère des versions de fichiers, pas de sources. Une version de sources est l'état de l'ensemble de tes fichiers (pour SVN, Git, Mercurial, Baraar...). Comment peut tu restaurer l'état de tes sources à la modification n donnée d'un fichier avec l'outil d'Eclipse ?

tu ne va pas tout restaurer en une fois et je ne dis pas que c'est facile
Si tu as ce genre de conflit au niveau des sources, tu as besoin d'un mécanisme de lock/modify/unlock (comme dans clearcase par exemple).
Pour l'instant, les choix de création de branche sont suffisamment bien faits pour n'avoir que très rarement ce genre de problème.
(cf. plus bas).

Au contraire, un exemple de théorie : http://martinfowler.com/bliki/FeatureBranch.html

très intéressant.

Pour le reste, tu confond version de sources (qui trouve sa place dans un gestionnaire de sources) et version logicielle (qui est le tag d'une livraison). Sans ajouter la caricature du projet OpenSource ( = non structuré). Sans prôner la multiplication des versions à outrance, versionner souvent permet d'isoler les modification. Si tu dois versionner uniquement l'ensemble du travail fini, tu a plus de chance d'introduire, d'amplifier, et de rendre difficilement identifiable un "bug" (je veux rester générique).

non, je ne confonds pas. Je parle intentionnellement de version logicielle car la version de sources en est un sous-produit. L'ensemble des révision de SVN est inutile si on est incapable d'associer ces révisions à des corrections et donc des versions spécifiques des différents composants de notre application.

Au niveau du dev, c'est pour permettre du travail concurrent qu'on crée les branches.

Sauf que l'intelligence fait que, dans une branche, le travail est beaucoup plus rarement concurrent.
les besoins de dev font qu'on peut se synchroniser et développer dans les quelques composants communs impactés un dev après un autre.
suffit juste de communiquer un peu

On ne va pas se les comparer, mais je rajouterai que beaucoup de développeurs n'y comprennent rien tout court.

tiens, on dirait qu'on a les mêmes développeurs :p

----------------
Je ne quote pas mais je rebondis/réponds au commentaire d'Aéris22 qui montre différents usages que je trouve très intéressant, notamment sur l'aspect intégration/revue de code.

Pour l'instant, il n'y a aucun SCM qui permet de valider facilement l'intégration de plusieurs lots de dev en production :
le temps entre la livraison et la MEP est trop important pour être atomique
-> les méthodes passaient souvent par des branches d'intégration puis merge dans le tronc (merdique & souvent illisible)

C'est vraiment le point qui pèche :
on est capable de se baser sur un référentiel et de créer plusieurs lots de développement.
on est déjà beaucoup moins capable de merger proprement ces différents lots selon leur MEP et donc de propager l'évolution du référentiel aux autres développements en cours.

Clearcase a une solution "simple" : il est tellement rigide qu'on n'a pas le choix, il râle si on n'est pas à jour.

SVN à l'inverse est beaucoup trop souple et permissif.
Et ça devient le bordel quand on a n composants avec m développement en cours (n x m branches sur lesquelles propager les modifs, c'est pas gagné).

Donc, cette solution de "triple" repository avec push sous git est très élégante :
- 1 repository pour le dev
- 1 repository pour l'intégration/release (on peut passer l'IC, les tests, intégrer plusieurs devs séparés, etc, et donc au final, accepter ou rejeter la livraison)
- 1 repository final public qui représente la production

A voir pour industrialiser la chose mais c'est très intéressant, je trouve !

[pseudocode]

Pour ma part, je trouve que les gestionnaires de version suivent l'évolution naturelle des méthodes de développement.

1990 : CVS a été créé pour répondre au problème des développements en parallèle : référentiel central (trunk), branches, révision par fichier, ...

2000 : SVN est un raffinement de CVS pour répondre au problème de traçabilité des changements : n° de révision global, gestion des répertoires, métadonnées...

2005 : GIT a été créé pour répondre au problème de merge d'un référentiel avec de multiples branches potentiellement très éloignées : fichier identifiés par hashcode, snapshot de tout le répertoire source, hierarchie des commits...

[martopioche]

@Aéris22 : Bon résumé. Je n'ai fait que répondre aux remarques précédentes, mais le fait est que la décentralisation permet des workflows de gestions de sources plus élaborés. La documentation de Bazaar en détail assez bien. D’ailleurs, il me semble que le développement du noyau Linux suit le modèle avec Gatekeeper par pull. Ce modèle peut se traduire par pull du responsable du projet des repos des différents responsables de composants, refus ou acceptation et intégration.

tu ne va pas tout restaurer en une fois et je ne dis pas que c'est facile

Ben si justement. Il est rare qu'un fichier soit isolé et indépendant des autre, donc pour avoir des sources cohérentes, il faut récupérer l'ensemble des états. Tiens, prend le cas d'un refactoring type changement de nom de package...

Si tu as ce genre de conflit au niveau des sources, tu as besoin d'un mécanisme de lock/modify/unlock (comme dans clearcase par exemple).

Pitié, plus jamais... Le modèle lock/modify/unlock, permet uniquement de protéger le référentiel d'un merge au prix d'une productivité réduite et l'affectation à plein temps d'un admin' au déblocage des fichiers verrouillés. Je sais que je blesse un amateur de Clearcase en écrivant ça et oui je sais que le highjack existe Mais par L/M/U, tu ne fait que t'approprier un fichier, en aucun cas tu ne peux avoir de suivi de son état.

L'ensemble des révision de SVN est inutile si on est incapable d'associer ces révisions à des corrections et donc des versions spécifiques des différents composants de notre application.

Je suis d'accord pour dire que seul les "livrables" sont réellement importants, mais je le répète : les tags sont là pour les caractériser. Les versions "intermédiaires" servent au suivi technique. Je prends un exemple perso : une maintenance sur un code, pas de doc (commentaire), pas de tests unitaires et besoin de refactorer pour isoler des modifications. Si je suis ton raisonnement, je ne commit qu'à l'issue de la maintenance. Or pour moi, il y en a au moins 3 : après ajout des tests (comme ça les autres devs en profitent), après le refactoring (modification de la structure à isofonctionalité, les autres devs peuvent déjà s'y adapter) et enfin l'évolution en elle même.

Au niveau du dev, c'est pour permettre du travail concurrent qu'on crée les branches.

Pour Clearcase oui Svn et ses successeurs permettent justement de travailler de manière concurrente sur la même branche. Les autres branches servant à tout ce qui s'éloigne de l'objectif premier. De plus, Git, Mercurial et Bazaar sont plus efficaces pour les merges que SVN du fait de leur conception (un commit est un changeset et non une nouvelle version).

Donc, cette solution de "triple" repository avec push sous git est très élégante :
- 1 repository pour le dev
- 1 repository pour l'intégration/release (on peut passer l'IC, les tests, intégrer plusieurs devs séparés, etc, et donc au final, accepter ou rejeter la livraison)
- 1 repository final public qui représente la production

A voir pour industrialiser la chose mais c'est très intéressant, je trouve !

Comme je l'ai dis plus haut, va voir les workflows proposés dans la doc de Bazaar (rhaaa bon, c'est là : http://doc.bazaar.canonical.com/bzr....workflows.html ). Tant qu'on y est, jette un oeil là dessus : http://hginit.com/00.html . J'ai fait du Clearcase, du SVN et du décentralisé. J'ai aidé à migrer dans tous les sens (non pas vers clearcase, faut pas déconner non plus ) et je le répète : pour comprendre chacun de ces trois mondes, il faut faire abstraction de ce qu'on connait des autres.

PS:

tiens, on dirait qu'on a les mêmes développeurs :p

C'est juste que tu a les même profils de développeurs partout qui va du superpassionné toujours au top d'un coté et celui qui vient juste justifier son salaire de l'autre

[Traroth2]

Des défauts, il y en a de nombreux : l'impossibilité de modifier la structure arborescente d'un repository, ce qui est pourtant une information métier, et non technique (typiquement, en Java, si je déplace une classe d'un package à l'autre ou si je renomme un package), ou tout bêtement le fait de se retrouver avec un répertoire .svn dans chaque répertoire du répository (là où Git se contente d'un répertoire .git à la racine du repository.

[Traroth2]

mais surtout, avant les problèmes de l'outil, ce sont principalement les personnes qui ne savent pas l'utiliser.

Voila exactement le problème : ces outils sont souvent trop complexes à utiliser. Un bon outil est un outil qui sait se faire oublier. Un développeur a (ou devrait) avoir d'autres préoccupations que d'apprendre à utiliser des outils compliqués.

Personnellement, j'ai utilisé CVS, SVN et maintenant Git, et Je préfère Git, car il retombe toujours sur ses pieds en cas de problème (pour l'instant en tout cas). Mais à certains moments, il ne fait pas immédiatement ce que je veux, et je suis obligé de me plonger dans la documentation pour que ça marche, et je n'ai tout simplement pas que ça à faire ! C'est un distraction de ce qui constitue mon véritable travail : l'ingénierie logicielle. Analyser des problématiques, trouver des solutions techniques, concevoir des solutions logiciels, les réaliser ou les faire réaliser. Voila mon métier. Pas me prendre la tête avec un logiciel qui n'est pas capable de me laisser faire simplement ce que j'ai besoin de faire !

[ac_wingless]

On peut aussi se demander pourquoi Perforce est en train de gagner du terrain par rapport à SVN (ou SVN est en train d'en perdre par rapport à Perforce...) alors qu'ils sont très proches fonctionnellement.

Et si une partie des problèmes de SVN étaient moins fondamentaux que ceux mentionnés dans cette discussion? Après tout, Perforce est pénible pour les fusions de branches, mais avec les superbes outils de merge et de micro-inspection lors des merge, on s'en sort très bien. Perforce ne distingue pas commit de push, mais avec il est (presque trop) simple d'embarquer en réunion une copie locale du dépôt, et de refusionner les commits (qui deviennent donc "locaux" par magie) au retour. Pareil pour les renommages, fort lourds sous Perforce: on peut les rendre relativement indolores par des filtres de vues.

Donc je pense que les problèmes de SVN viennent plus de ses outils que de ses problèmes fondamentaux. Sinon, personne ne paierait 800$ par an par poste pour Perforce, qui ne propose rien de mieux dans son principe.

On a eu récemment un stagiaire qui ne jurait que par Mercurial. Il avait raison sur toute la ligne, mais il a bien été forcé d'utiliser Perforce, et a découvert la simple "time-lapse view". Rien que ça lui a fait admettre que ça valait la peine de se faire c... avec un vieux truc pourri, parce qu'au bout du compte, nous sommes là pour faire notre travail le plus efficacement possible, pas pour respecter des principes de travail les plus élégants possibles. Alors quand SVN combine de vieux principes de travail avec des outils dépassés, il ne faut pas s'étonner de son sort.

[FotoXe33]

Je ne suis pas un pro en SVN ni un grand utilisateur (ni d'aucune autre méthode du reste), mais j'ai tout de même bosser dessus pour un projet en entreprise et je ne peut pas dire que j'en garderais un bon souvenir.
Entre les conflits où ils faut remplacer par la version précédente et faire des coupé/collé pour lui signaler que "youhou ya plus de conflit" ou encore les dossiers fantômes qui restent sur le serveur et ré-apparaissent à chaque update...
Bref vraiment pas gégé le SVN, la prochaine fois je test les autres.

[jmi57]

Ca fait 1 an que j'utilise SVN sur 3 missions différentes (dont 2 clients). La gestion de conflits est très bien faite, je trouve, quand on est 2 ou 3 développeurs à avoir modifié le même code au même endroit au même moment... (ce qui arrive relativement rarement).C'est sûr que ça fait perdre un peu de temps, mais si tous les développeurs ont le réflexe de récupérer et commiter très souvent les modifs, ça passe bien. Ca évite justement de partir sur un truc complétement incohérent par rapport à ses collègues, ou au contraire de développer la même chose en parallèle. Ca peut arriver en RMA, dans le cas où 2 anos sont dus au même code.
Tout ça pour dire que je ne comprends pas le coup du commit "hors connexion".

Après c'est vrai qu'on travaille tous sur le "trunk", les branches ne sont utilisées que pour les parties "expérimentales". Les tags sont créés à chaque livraison. Je pense que ça doit être en effet chaud pour ceux qui travaillent chacun sur une branche dans leur coin...

Oui il arrive parfois que SVN "déconne", et qu'il faille ajouter un espace pour qu'il réagisse. Ca a dû m'arriver 1 ou 2 fois cette année, Netbeans ou Eclipse m'ont fait des choses bien plus bizarres...

Sinon, je ne connais pas GIT puisque SVN est imposé la plupart du temps par les clients de toutes façons. SVN suffit, mais peut-être que GIT ou PERFORCE est mieux !

[NikeOfAllTrades]

Salut à tous.

J'utilise Bazaar quotidiennement depuis six mois, dans un projet d'une centaine de développeurs + tous les autres committers externes vu qu'il s'agit d'un projet open source. Pour ceux qui ne connaissent pas, c'est très similaire à Mercurial ou git.

Pour reprendre ce qui a été dit plus haut, je trouve effectivement que la possibilité de faire des commits locaux est un avantage, mais si déterminant que ça. Les commits locaux forment une technique de travail purement individuelle. Si vous êtes obligé par votre travail de faire du subversion et que vous ne pouvez pas vous passer de commits intermédiaire, qu'est-ce qui vous empêcherait de maintenir un repo git pour vous et de commiter sur le svn pour les autres?

Le plus gros avantage que je vois dans l'utilisation d'un DVCS, tout du moins avec un repo central possédant une configuration similaire à celle du notre qui n'est autre que Launchpad, c'est la possibilité qu'a tout un chacun de créer une feature branch. Vous avez créée une modif mais vous n'avez pas le droit de la pusher sur la branche de référence? Pushez sur une nouvelle branche et créez un merge proposal!

La où avec subversion il faut soit donner les droits de commit à tous les développeurs (au risque que le petit nouveau qui ne sait pas encore bien se servir d'un VCS bousille tout) soit interdire tout et obliger les gens à envoyer des patchs via un ticket de bug tracker (super, c'est user friendly à mort les .patch), avec un DVCS tout le monde crée sa modif, publie sa branche, et le responsable review puis merge.

Dans ma boite, depuis quelques mois pratiquement plus personne n'a le droit de commiter sur les branches de référence des différents projets, même pour un bug. Même si il n'y a que trois lignes à changer on crée des features branches pour tout, il reste juste ensuite à prévenir le responsable du projet qui fera le merge. On a même un système automatique qui lance les tests sur les feature branches en plus du trunk. Du coup notre trunk est stable en permanence. Mais bon, c'est vrai que les responsables de projets passent la moitié de leur temps à reviewer/merger...

[engi]

Pour ma part, j'ai travaillé longtemps avec CVS.
Le trouvant un peu vieillissant, je suis passé à Subversion avec sa floppée d'outils tous aussi pratiques les uns que les autres : VisualSVN Server, Tortoise, etc ...
Pour reprendre les dires de certains, je trouve SVN assez pratique et plutôt transparent à l'usage, sauf pour les merges de deux branches et les conflits qui sont assez pénibles à gérer, et je dis ça en ayant géré que des petits projets avec peu de développeurs.
Ne souhaitant pas "mourir" idiot, je jetterai bien un coup d'oeil à Git et autres.
Mais par quoi commencer ?
Je suis très habitué à l'intégration de Subversion dans le shell Windows avec TortoiseSVN. Existe-t-il des outils similaires pour Git ou Bazaar ?
Si ce n'est pas la cas, et sachant que je travaille presque exclusivement avec RadStudio 2010, existe-t-il des pluggins pour cet IDE ?
Je suis preneur de toute information ...
A+

[Aéris22]

Je suis très habitué à l'intégration de Subversion dans le shell Windows avec TortoiseSVN. Existe-t-il des outils similaires pour Git ou Bazaar ?

TortoiseHG est dispo pour Mercurial, et TortoiseBzr pour Bazaar
TortoiseGit existe aussi mais Git et Windows ça doit bien faire au moins 42…

Si ce n'est pas la cas, et sachant que je travaille presque exclusivement avec RadStudio 2010, existe-t-il des pluggins pour cet IDE ?

Des plugins existent pour les IDE «classiques» (Netbean, Eclipse…), mais je ne sais pas pour ton IDE qui me semble assez exotique.

[engi]

Merci pour ces infos !

RADStudio = Delphi & C++ Builder = exotique ?

[NikeOfAllTrades]

RADStudio = Delphi & C++ Builder = exotique ?

Ho que oui.

Du Delphi et du C++ en 2011, exotique c'est le moins que l'on puisse dire.

En dehors de ça, n'utilisez pas Bazaar, c'est utilisé presque uniquement sur Launchpad et ça n'apporte rien par rapport à Mercurial ou git.

[ac_wingless]

TortoiseHG est dispo pour Mercurial, et TortoiseBzr pour Bazaar
TortoiseGit existe aussi mais Git et Windows ça doit bien faire au moins 42…
Des plugins existent pour les IDE «classiques» (Netbean, Eclipse…), mais je ne sais pas pour ton IDE qui me semble assez exotique.

Subversion est intégré dans RadStudio XE. Attention cependant, certains forums rapportent des problèmes de régression depuis 2010.
Par ailleurs, notre société utilise RADStudio depuis longtemps (BCB 2006) avec Perforce sans problème particulier, les fichiers inaccessibles étant de toute façon interdits en écriture.

[danucc]

Moi j'utilise Bazaar pour sa simplicité et son efficacité.
Je n'ai pas comparé avec Git ou Mercurial mais par rapport à SVN j'ai beaucoup moins de problème entre versions du gestionnaire de version et surtout entre plateformes (Linux/Windows).

Danilo

[yrsone]

J'ai eu à administrer que 2 outils : Clearcase et SVN.

Première conclusion, le plus gros problème de ces 2 outils, il se situe entre le clavier et la chaise.

Clearcase est un outil très puissant (la gestion des merges et des streams miam) mais manipulé par des bourrins avec 2 mains gauches et qui ne comprendront jamais rien ... c'est une merde infâme qui peut partir en vrille pour un rien et qui peut devenir un enfer à débloquer. Administrer cet outil, plus jamais !

Comparé à Clearcase, SVN est certes moins puissant mais un véritable bonheur à remettre en marche en cas de problème.

Après en ce qui concerne Git & co, il faut du temps ... il faut faire bouger le mammouth (utilisateurs et décdeurs) et la mise en place d'un gestionnaire de versions peut être vécu comme une abomination apocalyptique par les "vieux", réfractaires à tout et qui ne comprennent pas pourquoi on ne peut plus directement développer sur les plateformes de production -> Ton outil, c'est de la merde !

Git est trop jeune et les interconnexions avec d'autres outils ne sont pas encore assurées donc dans certains cas, ca devient rédhibitoire.