1. Oui
3. TFS
4.
Parce que:
- nous sommes des vendus à Microsoft;
- c'est garantie que ça marche directement avec les nouvelles versions de VS;
- bonne intégration à VS.

1. Oui
2. Oui
3. Si si, mais parfois le matin.
4. Uniquement quand je m'assier sur du froid, après ca passe.
5. Juste un café, merci.

Donc.
ClearCase pendant les années où je travaillais dans une boîte qui s'avait se l'offrir et avec tout le mal que j'ai au sujet de clearcase, je dois avouer que je n'ai jamais vu un versioning graphique aussi beau/pratique/facile et c'était...il y a 10 ans exactement.
(ceci est une question/challenge plus qu'une affirmation, s'entend)

Depuis que je suis en mode "PME-compile-ton-serveur-mail-toi-même-et-le-premier-qui-arrive-fait-du-café-pour-les-autres" , c'est bien sûr CVS, les Snuls, bien entendu.

Cela dit, à vous lire, je devrais bientôt envisager de quiter CVS pour aller vers SVN, chic!
J'adore me frotter à la résistance au changement des collègues!
Vais essayer de trouver des arguments valables...

1. J'utilise plus d'un système de versioning: oui.
2. /
3. Les serveurs sont en SVN, je tourne git sur mon client.
4. SVN, parce que c'est la référence de facto. CVS, c'est l'âge de pierre à côté de SVN.
En local, j'utilise git (qui s'interconnecte formidablement bien avec un serveur SVN) qui offre une quantité phénoménale de fonctions supplémentaires pour autant qu'on arrive à assimiler son fonctionnement vraiment très différent des server-centrics.

Pour moi, ceux qui n'utilisent pas de contrôle de source pour leur code sont soit des ignorants, soit des criminels. Je trouve inadmissible qu'on n'enseigne pas les bases du contrôle de version dans les écoles d'infos, ça m'a très souvent sauvé la vie et ça facilite grandement la gestion des versions d'un logiciel.

CVS, je l'ai pas mal utilisé mais il a des défauts énoooormes que SVN corrige. Pour n'en citer que qq uns:
- CVS gère les versions fichier par fichier. Pour défaire une correction qui fout la merde, il faut chercher dans les fichiers modifiés dans les qq secondes autour de la modif. Et si deux personnes ont commité en même temps, c'est le bordel. Sur SVN, les modifs sont atomiques, des modifs sur 15 fichiers sont toutes faites avec le même numéro de révision ou ne sont pas faites du tout.
- CVS ne gère pour ainsi dire pas la suppression des fichiers.
- CVS ne supporte pas du tout le renommage des fichiers.
- CVS travaille fichier par fichier, SVN par révision.
- Le branching/mergeing dans CVS est un cauchemar absolu. Dans SVN, ça marche assez bien.

Git, je l'utilise depuis que j'ai un Mac. Sous Windows, c'est pas encore au point. Pas étonnant pour un logiciel de Linus Torvalds.
En fait, git copie le repository SVN entier. Et il le fait en utilisant moins d'espace disque que SVN pour une seule révision. De plus, il ne met pas de .svn partout, c'est plus propre quand on fait un .tar.gz du code.
L'avantage majeur de git est que je peux travailler offline. A chaque modif atomique je fais un commit en local. Une fois que je suis content de mes différents commits, je demande à git de me resynchroniser et hop, il transfère mes commits git dans le serveur SVN. Magique.
On peut ainsi éviter de perturber les habitués de SVN tout en tirant soi-même parti de la puissance de git.

J'ai aussi utilisé Hg (Mercurial) à une époque. C'est un outil nettement mieux fini sous Windows mais malheureusement son interface vers SVN n'est vraiment pas au point. Dommage parce que je le préférais au départ.

J'ai aussi utilisé dans le passé Visual SourceSafe et ClearCase, les deux ayant le mérite de fonctionner mais chacun avait des défauts qui rendaient mon travail quotidien assez pénible.

Pour compléter ta remarque, on ne m'en a même pas parlé durant mes études, c'est parce que je connaissais des devs que j'ai souhaité m'y intérêsser durant mon stage, sur lequel on était 2.

J'ai voulu utiliser SVN avec mon partenaire, il m'a dit qu'il trouvait que ça fonctionnait mal, et qu'il n'en voulait pas

Résultat, on faisait des modifications tour à tour sur un fichier via un ftp sur une vm.. Plus d'une fois ça a conduit au coup du "mais put*** t'as quand même pas remplacé ma modif?"

Nours > Je t'assure qu'avec un svn, ça arrive aussi

oui



(je suis consultant, pour resituer un peu)
dans mes missions précédentes, Continuus/CM Synergy
aujourd'hui, Advitium



ben en tant que consultant, je choisis pas les outils sur lesquels je travaille
mais les raisons étaient les suivantes
Continuus/ CM Synergy: parce que produit évolué à l'époque et dispo en environnement Windows et unix
Advitium: pour la gestion système (pas uniquement software) multi-site (perso, c'est pas celui que j'aurai choisi mais bon)

La belgique veut se doter d'un système de versionning pour la gestion des différentes versions de ses gouvernements.

La Release 5 de Leterme Version 2 connait un blocking point important et il est important de ne perdre aucune trace des bug fix en cours. Le module OpenVLD vient d'être retiré de la production mais continue à tourner sur le système Chambre. Il semblerait que la procédure de vote forcé soit presque lancée sur ce système. Mc Afee recommande l'installation de "Conflit D'intérêt" Version 6 (version d'évaluation de 120 jours).

rfr > le problème pourrait être facilement résolu par un script DOS, pourtant...

mv flandre /dev/null

???

Selon ta logique, avec ton "mv flandre /dev/null", je suis aussi dans le "/dev/null"

grep francophones flandre.dat > saved_people.dat
mv flandre.dat /dev/null

D'ou l'utilité du versioning

Ouais mais c'est vache parce que sur quelle base on dit que qq'un est francophone de Flandres ? Mon fils est enregistré en flamand, ma femme et moi non, cela ferait de lui un flamand ?

Le problème en informatique, c'est que le client est toujours chiant

A qui le dis-tu ? Franchement, je trouve le client interne plus chiant que le client externe parce que "Tu pourras bien faire une exception pour lui qui te connait si bien même qu'il te dit bonjour depuis une semaine après 5 ans pour te le prouver..."