Pourquoi éviter le verrouillage pessimiste dans un système de contrôle de version?

Question

Basé sur quelques articles que j'ai lus concernant le contrôle de version, il semble que les gens pensent que le verrouillage pessimiste dans un système de contrôle de version est une mauvaise chose. Pourquoi? Je comprends qu'il empêche un développeur de soumettre un changement tandis qu'un autre a le fichier extrait, mais alors quoi? Si vos fichiers de code sont si gros que vous avez constamment plus d'une personne travaillant sur eux en même temps, je soumets que vous devriez réorganiser votre code. Brisez-le en unités fonctionnelles plus petites.

L'intégration de modifications de code simultanées est un processus fastidieux et sujet aux erreurs, même avec les outils qu'un bon système de contrôle de version fournit pour le rendre plus facile. Je pense qu'il devrait être évité si possible. Alors, pourquoi le verrouillage pessimiste est-il découragé?

Answer 1

Cela dépend de votre projet et de votre équipe en général. Le verrouillage pessimiste est bon car il est facile à comprendre - un dev à la fois, et aucune fusion requise! Cependant, la mauvaise chose à propos de est exactement cela - un dev à la fois. J'ai la situation en ce moment où un collègue est allé sur place, et avant qu'il ne parte, il a tout vérifié afin que s'il devait réparer des bugs, il puisse revenir et vérifier tous ses changements dans .... bon pour lui , moche pour moi et le reste de l'équipe de développement à la base.

Si vous pouvez contourner le verrouillage pessimiste dans votre équipe, alors il est bon de l'utiliser, vraiment, la plus grande raison pour laquelle les gens le détestent est parce que sa pratique par défaut Visual SourceSafe. Si vous n'êtes pas sûr de fusionner de nombreux changements, vous avez une autre raison de l'utiliser: si vous avez déjà utilisé un SCM verrouillé optimiste, et que vous avez réussi une fusion, vous saurez à quel point il est difficile de récupérer.

Si vous pouvez gérer la fusion, alors le verrouillage optimiste est supérieur et je le recommande, mais vous n'avez pas besoin de remettre votre carte geek si vous ne voulez pas l'utiliser.

Answer 2

Les développeurs de logiciels sont toujours optimistes - il suffit de regarder leur estimation des compétences! En pratique, nous constatons que les conflits sont rares et que les avantages de ne pas avoir à s'inquiéter du verrouillage l'emportent sur l'étape occasionnelle de la résolution des conflits.

Answer 3

1. Jouez avec Source Safe et laissez un développeur partir pour deux semaines de vacances. Ajoutez à cela que les administrateurs VSS ne sont pas là. Maintenant, vous avez un correctif à afficher, mais vous ne pouvez pas à cause du développeur
2. Si vous avez travaillé sur plusieurs fonctionnalités et/ou corrections de bugs. Peu importe la taille de votre code, vous aurez toujours un conflit pour un fichier central.

Answer 4

Le verrouillage pessimiste est (expérience personnelle) dans le domaine de la collaboration. Il est parfois facilement remplacé par une bonne communication d'équipe. Juste en disant "Hey, je vais travailler sur ces quelques fichiers pendant un moment".

J'ai travaillé en équipe de 2 à 6 personnes sans verrouillage et nous n'avons jamais eu de problème, au-delà de quelques fusions habituelles et nécessaires.

J'ai également travaillé une fois avec le verrouillage d'un projet hébergé Visual SourceSafe. C'était IMHO contre-productif.

Answer 5

• Vous n'avez pas toujours la possibilité de pause fichiers en dehors
  • fichiers de configuration
  • fichiers XML
• fichiers Même relativement petits peuvent encore contenir des parties distinctes que plus d'un le développeur doit avoir accès à
  • Bibliothèques
  • Utilities
• Fusion outils sont beaucoup plus intelligents qu'ils ne l'ont jamais été
  • Les conflits sont plutôt rares
• Réduit les retards dus aux développeurs ayant des fichiers « accidentellement » vérifié

Answer 6

Si un développeur ne peut pas gérer les conflits de fusion et de résolution, il devrait être rééduqué.Il est courant que même de petits fichiers génèrent des conflits. Par exemple, avec les JSP, une personne (développeur Web) peut modifier le code de disposition et quelqu'un d'autre peut modifier l'API pour le modèle utilisé par la JSP.

Answer 7

1. Bob doit modifier FooBar.java
2. John l'a vérifié pour l'édition
3. Bob édite sa copie locale de toute façon et il enregistre comme FooBar.java.bak
4. Lorsque John vérifie son dans, Bob il vérifie
5. copies Bob FooBar.java.bak dessus et le vérifie dans
6. John arrive à sa fonction réimplémentez

Je l'ai vu arriver encore et encore. Les développeurs font cela parce que ce processus est ennuyeux:

1. Bob doit modifier FooBar.java
2. John l'a vérifié pour l'édition
3. Bob doit attendre jusqu'à ce que tourner les pouces John se fait

Verrouillage pessimiste ressemble à l'heure amateur, désolé.

Answer 8

si vos fichiers de code sont si grands que vous avez constamment plus d'une personne travaillant sur eux en même temps

Si tel est le cas, il est temps pour « êtres humains » pour prendre en charge et coordonner les changements. Dans le cas idéal, et si votre gestion de projet est bonne, vous frapperez rarement une fois où vous essayez de changer un fichier verrouillé parce que quelqu'un aura coordonné des choses de sorte que cela ne se produira pratiquement pas. En d'autres termes, vous savez que 'Bob' fait un grand nombre de changements dans les composants X/Y/Z, si vous avez une correction de bogue dans le composant X, vous saurez parler à Bob avant d'essayer de soumettre vos changements.

Comme je le dis est idéal, verrouillage)

Answer 9

est Pessimiste une bonne idée si graves conflits vont probablement. Pour la plupart des programmes, vous ne verrez aucun conflit sérieux, le verrouillage pessimiste est donc inutile. Les exceptions à cette règle sont les suivantes:

• Travailler sur des fichiers binaires dans lesquels vous ne pouvez pas vraiment fusionner - les ressources artistiques (modèles, textures, etc.) en sont un bon exemple.
• Travailler avec des utilisateurs non-techniques qui ne savent pas comment fusionner, et ne veulent pas apprendre (surtout des artistes, mais certains rédacteurs techniques vont aussi s'y intéresser).
• Travailler sur de très gros fichiers qui ne peuvent pas être facilement fusionnés ou fragmentés en fichiers plus petits en raison du haut degré de complexité (jamais vu une situation comme celle-là, mais je suis sûr que c'est possible).

Sinon ...

Answer 10

En ce qui concerne le cas avec Bob et John, les systèmes coopératifs comme svn n'empêche pas ce scénario plus qu'un système de verrouillage fait. Je peux 'mettre à jour' FooBar.java, qui satisfait SVN que j'ai la dernière édition, puis supprimer ce fichier localement et écraser avec ma propre copie personnelle que j'ai faite sans tenir compte de la version de base, et vérifier dans, heureusement détruire les changements de l'autre gars. Aucun système, verrouillé ou non, n'empêche cela, donc je ne vois pas l'intérêt de l'introduire même dans le débat.

La vraie question est de décider ce que votre équilibre est entre

probabilité d'erreurs de fusion vs gêne occasionnée par les fichiers de verrouillage

L'idée que ce soit un blocage ou d'un système non-verrouillage est « supérieure "est un non-sens. J'ai utilisé VSS, dans son mode de verrouillage complet par défaut, avec 6 développeurs, et cela a fonctionné comme un rêve. De temps en temps, quelqu'un oublie de libérer une serrure et nous devons les traquer ou casser la serrure manuellement et fusionner à la main quand ils sont revenus, mais c'était très minime. J'ai vu svn bousiller sa fusion automatique plus d'une fois, de sorte que je n'ai pas vraiment confiance en elle. Il ne marque pas toujours un «conflit» lorsque deux personnes ont modifié le même fichier d'une manière qui ne peut pas être fusionnée automatiquement. Inversement, j'ai vu des gens s'impatienter avec les verrous de VSS, éditer leurs propres copies, et les regarder par-dessus le code des autres, et j'ai vu svn me rattraper quand je pouvais accidentellement essayer pour vérifier quelque chose qui a été changé par quelqu'un d'autre depuis la dernière fois que je l'ai vérifié. Mon point est, ce n'est pas un débat raisonnable à avoir. Le succès de l'un ou l'autre système descend à comment vous gérez les points de conflit quand ils se produisent, pas si un système ou l'autre est meilleur.