Проверка исходного кода Комментарии в верхней части исходных файлов

Question

Я заметил несоответствие с некоторыми исходными файлами в нашей системе, когда некоторые содержат комментарии проверки исходного кода, а некоторые нет. Эти комментарии автоматически добавляются в начало файла, когда он отмечен:

    * $Log:   //vm1/Projects/Morpheus/Sleep.bdy-arc  $
--
--   Rev 1.14   Apr 14 2009 15:32:52   John Smith
--Fixed bugs 2292 and 2230.

Это, кажется, было довольно распространенным во всех компаниях, с которыми я работал, но я должен признаться, что изо всех сил стараюсь понять суть. Обычно комментарии не так хороши, их часто оставляют люди, которые давно ушли, и даже когда они соответствуют высоким стандартам, их трудно связать с физическими изменениями кода.

Меня также поразило, что вы физически изменяете файл, который вы проверяете. Теперь это может не быть такой проблемой с файлами, которые будут скомпилированы, но может быть катастрофой для других, например, Файлы JavaScript.

Так что, на самом деле, мой запрос заключается в том, что послужило мотивацией для предоставления этой функциональности в первую очередь? Кто-нибудь на самом деле находит эти комментарии полезными?

Кроме того, мне было бы интересно узнать, поддерживается ли эта функция в системах контроля версий. Я знаю об этом с PVCS, VSS и Subversion ( Subversion Keyword Substitution ), однако мне интересно, доступна ли она и в некоторых из наиболее популярных DVCS.

Ваша помощь, как всегда, высоко ценится.

Answer 1

Вы правы - в итоге это не очень полезная функция систем контроля версий! Да, компаниям нравится контрольный журнал, но это обеспечивается командой log системы контроля версий; да, это означает, что журнал доступен, если нет системы контроля версий - но в этом случае Fixed bug 1234, вероятно, не очень значим :-) И, как вы намекаете, чтобы связать изменения с конкретными линии, вам все еще нужна помощь системы контроля версий.

Вы также правы в том, что изменение файла во время его фиксации может вызвать проблемы - я однажды видел проблему, когда коллега тщательно следил за тем, чтобы его код компилировался, а затем фиксировал его, только для того, чтобы воспламениться, потому что файлы, которые он ' Я совершил не скомпилировать. Оказалось, что комментарий был чем-то вроде Clean up /tmp/*.txt, а компилятор C рассматривал /* как символ начала комментария (и жаловался, потому что он уже был внутри комментария).

Другая проблема с журналами в файлах заключается в том, что они имеют смысл только для линейной работы - если вы разрабатываете с несколькими ветвями (так, как поощряют инструменты с распределенным исходным кодом, такие как git / mercurial / bazaar), имеющие журнал в исходном файле. сам по себе служит только для создания конфликтов слияния почти все время.

По этой причине современные инструменты, как правило, не реализуют эту функциональность. Действительно, subversion не - его подстановка ключевых слов преднамеренно не позволяет включать историю журнала.

Answer 2

Так что, на самом деле, мой запрос заключается в том, что послужило мотивацией для предоставления этой функциональности в первую очередь? Кто-нибудь на самом деле находит эти комментарии полезными?

В некоторых компаниях контроль аудита является серьезной проблемой. Аудиторы хотят иметь возможность отслеживать от системы инцидентов до фактических изменений кода. Fixed bugs 2292 and 2230. предоставляет трассировку от кода к системе инцидента.

По той же причине некоторые компании требуют номер инцидента как часть комментариев в журнале изменений контроля версий.

Answer 3

Так что на самом деле мой запрос мотивация в концепции обеспечения этот функционал в первом пример? Кто-нибудь на самом деле находит эти комментарии полезны?

Когда источники зеркалируются во внешнее местоположение (пакеты исходного кода, индекс исходного кода и т. Д.), Информация об управлении версиями может быть недоступна. Для таких случаев эта информация может быть полезна.