Un développeur devrait-il être autorisé à utiliser VSS s'il le préfère?

J'ai présenté Mercurial à mon département. Je l'adore, mais c'est ma première expérience de contrôle de version. Je l'utilise avec NetBeans PHP pour le développement web.

Un autre développeur qui travaille sur les applications internes de l'entreprise aime utiliser Visual Source Safe et ne veut pas changer. Il travaille dans un environnement Visual Studio.

Tous les autres développeurs ont acheté Mercurial sauf celui-ci. Cependant, pour la plupart, nous travaillons tous de manière assez indépendante.

J'essaie de déplacer ce département dans la bonne direction, j'ai créé tout le monde avec un compte sur Kiln, j'espérais que tout le monde utilise Fogbugz sur la route (car il n'y a actuellement aucune base de données de bogues en cours de maintenance.) J'ai jamais utilisé VSS mais j'entends de très mauvaises choses à ce sujet.

Serait-il préférable de lui permettre de continuer à utiliser VSS si c'est ce qu'il préfère, ou serait-il dans le meilleur intérêt de l'embarquer avec Mercurial?

serait-il préférable de lui permettre de continuer à utiliser vss si c'est ce qu'il préfère

Non. Il est inutile d'exécuter deux systèmes de gestion de sources différents en parallèle. Cela défie l'idée même que tous les développeurs sont connectés au même référentiel et en profitent pleinement.

Un seul développeur utilisant seul un système différent s'isole efficacement de l'équipe. Même si les projets ne se croisent pas, c'est toujours une mauvaise chose à faire.

Les efforts de maintenance doublés pour les deux systèmes sont un autre argument ici.

Je pense que vous devriez utiliser votre autorité ou transmettre le problème à la direction pour migrer rapidement le contenu de VSS vers Mercurial, puis fermer VSS.

PS En parlant de VSS, il est notoire de perdre des enregistrements ou d'endommager le code de toute autre manière lorsque vous vous y attendez le moins. Ça marche mais ça va régulièrement sur les nerfs. Si vous avez une meilleure alternative, évitez VSS.

Je n'envisagerais jamais d'autoriser un développeur voyou à utiliser un système de contrôle de source différent du reste de l'équipe.

Le contrôle des sources n'est pas seulement pour que je puisse trouver les versions précédentes de ce que j'ai fait, mais aussi pour que d'autres puissent les trouver (et la version actuelle). Ceci n'est pas négociable. Que se passe-t-il lorsqu'il part ou se fait écraser par un bus et que personne d'autre n'a accès à son code (qui peut même être écrasé par les administrateurs réseau lorsqu'ils essuient sa machine, sans savoir qu'il y avait son propre contrôle de source?

Je fais l'hypothèse que son code de contrôle de source peut être uniquement sur sa machine car personne d'autre n'utilise VSS.) Un développeur qui suggérerait même une telle chose n'est pas professionnel et cela me rendrait méfiant de tout son travail. Que ne veut-il pas que le reste d'entre vous voie?

VSS est également notoirement buggé. Son code n'est même pas sûr là-bas.

Personne ne devrait jamais utiliser VSS pour commencer.

Dites à votre développeur d'obtenir un plugin Mercurial pour Visual Studio.

Tout le monde devrait être sur le même système de gestion des sources. En outre, votre objectif ultime est également de mettre tout le monde sur le même système de suivi des bogues. Vous avez déjà fait la bonne chose en trouvant une solution étroitement intégrée.

Si vous avez du mal à les faire changer, essayez de l'aborder du point de vue de la carrière. S'ils travaillent ailleurs, cet employeur potentiel voudra probablement voir une certaine expérience de travail avec une configuration d'application de gestion de bogues / sources intégrée.

Je vais faire écho à ce que les autres ont dit, en ce sens qu'il est mauvais de lui permettre d'utiliser VSS et non Mercurial. Cependant, permettez-moi de jouer Devil's Advocate et de dire que vous pouvez le laisser glisser si, et seulement si, il s'engage toujours sur Mercurial afin que d'autres puissent accéder à son travail si nécessaire. L'OMI n'a rien de mal à utiliser vos outils préférés tant que vous n'empêchez pas les autres d'accéder au travail dont ils pourraient avoir besoin. Bien sûr, VSS est une poubelle donc il ne devrait pas être utilisé quoi qu'il arrive :)

Par exemple, je travaille dans une entreprise qui utilise SVN mais n'a pas le référentiel correctement configuré (pas de branches / tags / tronc, tout est simplement jeté sous un référentiel) et cela provoque des problèmes que personne ne sait comment résoudre. Je ne verrais pas de problème dans mon cas si j'utilisais, disons, Git localement mais que j'utilisais toujours git-svn pour pousser mes trucs vers SVN donc le reste de l'équipe l'a. Cela a-t-il du sens?

Il n'est pas bon qu'un développeur utilise un outil de contrôle de source différent. L'un des objectifs de l'utilisation du contrôle de code source est d'améliorer le travail d'équipe. Et il enfreint cette règle et peut causer beaucoup de problèmes plus tard, même si vous travaillez assez indépendamment récemment. Demandez-lui pourquoi il préfère VSS et dites-lui les inconvénients de travailler de cette façon.