La sémantique simplifiée pour la commande 'blame' est-elle une bonne chose?

Question

Je suis en train de travailler sur une nouvelle armureà base de structure de données pour le stockage de contrôle de version de l'histoire. Ce sera sans doute la cause de quelques guerres de religion, à savoir si c'est La bonne Façon De Faire les Choses quand il sort, mais ce n'est pas ma question maintenant.

Ma question a à voir avec ce que la sortie de blâme doit donner. Lorsqu'une ligne de code a été ajouté, supprimé, et fusionnés en lui-même un certain nombre de fois, il n'est pas toujours clair ce que la révision devrait obtenir blâmer pour cela. Notamment cela signifie que lorsqu'une section de code est supprimé, tous les enregistrements de ce avoir été, il y est allé, et il n'y a pas de blâme pour la suppression. Tout le monde je suis allé sur cette question avec a dit que d'essayer de faire mieux n'est tout simplement pas la peine. Parfois les gens mettent dans le hack que la ligne après l'article qui a été supprimé a son blâme changé à partir de ce qu'il était réellement à la révision lorsque l'article a été supprimé. On peut supposer que si la section est à la fin de la dernière ligne obtenir son blâme changé, et si le fichier vents vide alors le reproche fait vraiment disparaître dans l'éther, car il n'y a littéralement de nulle part à gauche pour mettre le blâme de l'information. Pour différentes raisons techniques je ne vais pas utiliser ce hack, mais supposons que la poursuite de mais cette totalement sans-papiers, mais de facto la norme de pratique sera sans polémique (mais n'hésitez pas à la flamme moi et de sortir de votre système).

De passer à ma question. Généralement à blâmer pour chaque ligne vous regardez l'histoire complète de l'endroit où il a été ajouté et retiré de l'histoire et à l'aide de trois voies de fusion (ou, dans le cas de criss-cross se confond, au hasard des conneries) et sur la base des relations entre celles-vous déterminer si la ligne doit avoir été fondée sur son histoire, et si elle ne devrait pas, mais est puis vous marquer comme nouveau avec la révision en cours. Dans le cas où une ligne se produit dans de nombreux ancêtres avec différents accuse ensuite, il choisit celui qui en héritent de façon arbitraire. Encore une fois, je suppose que la poursuite de cette complètement sans-papiers, mais de facto la norme de pratique sera prête pas à controverse.

D'où mon nouveau système diverge, c'est que plutôt que de faire un calcul compliqué de savoir si une ligne doit être dans la révision actuelle basée sur un calcul complexe de toute l'histoire, il regarde simplement les ancêtres immédiats, et si la ligne est dans l'un d'eux, il choisit arbitraire d'hériter de la faute de. Je suis en train de faire ce changement, en général pour des raisons techniques (et c'est tout à fait possible que d'autres blâmer les implémentations de faire la même chose, pour les mêmes raisons techniques et un manque de soin), mais après y avoir réfléchi un peu partie de moi préfère effectivement le nouveau comportement plus intuitive et plus prévisible que l'ancien. De quoi tout le monde pense?

Answer 1

J'ai en fait écrit un de le blâmer les implémentations de là-bas (Subversion's actuel, je crois, à moins que quelqu'un l'a remplacé dans la dernière année ou deux). J'ai aidé avec quelques autres.

Au moins la plupart des implémentations de blâmer de ne pas faire ce que vous décrivez:

Généralement à blâmer pour chaque ligne vous regardez l'histoire complète de l'endroit où il a été ajouté et retiré de l'histoire et à l'aide de trois façon de fusion (ou, dans le cas de criss-cross se confond, au hasard des conneries) et sur la base des relations entre celles-vous déterminer si la ligne doit avoir été fondée sur son histoire, et si elle ne devrait pas, mais est puis vous marquer comme nouveau avec la révision en cours. Dans le cas où une ligne se produit dans de nombreux ancêtres avec différents accuse ensuite, il choisit celui qui en héritent de façon arbitraire. Encore une fois, je suppose que la poursuite de cette complètement sans-papiers, mais de facto la norme de pratique sera prête pas à controverse.

En fait, la plupart blâme sont nettement moins complexe que cela et ne pas la peine d'essayer d'utiliser les relations à tous, mais ils ont juste marcher parents dans certains ordre arbitraire, à l'aide de simples delta structures (généralement la même structure interne quelle que soit la diff algorithme qu'ils ont utilise avant qu'il se transforme en sortie textuelle) pour voir si le morceau changé et, si oui, c'est la faute, et la marque de cette ligne comme fait.

Par exemple, Mercurial a tout simplement un processus itératif en profondeur d'abord de recherche jusqu'à ce que toutes les lignes sont mis en cause. Il n'essayez pas de prendre en compte le fait que les relations, il est peu probable qu'il blâmé celui de droite.

Git ne faire quelque chose d'un peu plus compliqué, mais encore, pas tout à fait comme vous décrivez.

La Subversion n'est qu'Mercurial n', mais l'histoire graphique est très simple, il est donc encore plus facile.

À son tour, ce que vous suggérez est, en fait, ce que tous d'entre eux font réellement:

Choisissez l'arbitraire d'un ancêtre et suivez le chemin vers le bas le trou de lapin jusqu'à ce qu'il fait, et si cela ne cause pas de vous avoir blâmé toutes les lignes, arbitrairement choisir le prochain ancêtre, continuer jusqu'à ce que tout le blâme est attribué.

Answer 2

Sur un plan personnel, je préfère votre simplifié option.

La raison: le Blâme n'est pas utilisé beaucoup de toute façon.

Donc je ne vois pas l'intérêt de perdre beaucoup de temps à faire une complète mise en œuvre.

C'est vrai. Le blâme est en grande partie s'est avéré être l'un de ces "pot d'or à la fin de l'arc-en-ciel" caractéristiques. Il avait l'air vraiment cool de ceux d'entre nous, debout sur le sol, rêver d'un jour où nous avons juste à cliquer sur un fichier et de voir qui a écrit des lignes de code. Mais maintenant que c'est largement mis en œuvre, la plupart d'entre nous en sont venus à comprendre qu'en fait, il n'est pas très utile. Vérifier l'activité sur l' blame tag ici sur un Débordement de Pile. Il est underwhemingly désolée.

J'ai rencontré des dizaines de "blâmer digne de" scénarios au cours des derniers mois seulement, et dans la plupart des cas, j'ai tenté d'utiliser le blâmer d'abord, et constaté qu'il soit lourd ou totalement inutile. Au lieu de cela, j'ai trouvé les informations dont j'avais besoin en faisant une simple filtré modifications sur le fichier en question. Dans certains cas, je pourrais avoir trouvé l'information à l'aide de Blâmer ainsi, j'avais été persistant, mais il en aurait fallu beaucoup plus de temps.

Le principal problème est le code de modifications de mise en forme. Le premier niveau est à blâmer pour presque tout ce qui a été répertorié comme... moi! Pourquoi? Parce que je suis le seul responsable de la correction des sauts de ligne et les tabulations, re-fonction de tri de l'ordre, de la scission des fonctions distinctes de l'utilitaire de modules, fixation commentaire fautes de frappe, et d'améliorer ou de simplifier le flux de code. Et si ce n'était pas moi, quelqu'un d'autre l'avait fait à un espace ou un bloc-déplacer quelque part le long de la manière. Afin d'obtenir un véritable blâme sur quelque chose qui remonte à une heure avant, je peux déjà vous rappeler sans l'aide de blâmer, j'ai eu à faire reculer les révisions et re-blâme. Et re-blâme de nouveau. Et de nouveau.

Donc, pour un blâme pour être réellement utile gain de temps de plus que le plus chanceux de situations, le blâme doit être en mesure de heuristicly faire son chemin passé de saut de ligne, les espaces et idéalement bloc de copier/déplacer des changements. Qui sonne comme une commande très grande, surtout quand récurer le changelog pour un seul fichier, la plupart du temps, il ne sera pas donner beaucoup de diff de toute façon et vous pouvez simplement passer au crible par la main assez rapidement. (La seule exception, peut-être, mal conçu source d'arbres, où 90% du code est bourré dans un ou deux ginormous fichiers... mais qui ces jours-ci en collaboration dans un environnement de codage fait beaucoup de plus?).

Conclusion: Donner un bare-bones de mise en œuvre de blâmer, parce que certaines personnes aiment à voir ", il peut blâmer!" sur la liste des fonctionnalités. Et de passer ensuite aux choses qui comptent. Profitez-en!

Answer 3

L'algorithme de fusion de lignes est plus stupide que le développeur. S'ils ne sont pas d'accord, cela indique simplement que la fusion est fausse plutôt que d'indiquer un point de décision. Donc, la logique simplifiée devrait en réalité être plus correcte.