Как бы вы объяснили риски, связанные с ключевым словом $ Log $?

Question

Кажется, я вхожу в ежегодную дискуссию об использовании ключевого слова $Log$. Моя точка зрения такова:

$Log$ - белая горячая смерть.

Все, что он делает - это внедряет незначительный спам в ваши исходные файлы. Любая информация, которую кто-либо считает, что она может получить из $ Log $, более доступна (и, вероятно, будет более точной) в вашей системе контроля версий.

Итак, вот вопрос: как бы вы объяснили программисту "старой школы" (который думает, что $ Log $ - это способ управления изменениями исходного кода), что у нас теперь есть лучшие инструменты?

Замечания CVSNT к $ Log $ - хорошее начало , но они просто недостаточно точны. На сегодняшний день самое близкое, что я нашел к одной строке, с которой мне удалось придумать: «$Log$ - это желание. Вы надеетесь на то, что спам попадает в ваш файл имеет любое отношение к тому, что действительно произошло с этим файлом. "

PS для ясности: когда я говорю «старая школа», я имею в виду старое в отношении, а не старое в годах. Моя первая зарплата в программировании (и тоже весьма скромная) была когда-то в 1986 году, и я никогда не думал, что $ Log $ - хорошая идея.

Answer 1

Я думаю, что Subversion FAQ также имеет хорошее объяснение.

$ Log $ - это ужас, когда вы начинаете объединять изменения между ветвями. Вы практически гарантированно получите конфликты там, который - из-за природы этого ключевого слова - просто не может быть разрешается автоматически.

Answer 2

В дополнение к тому, что сказали другие, попробуйте добавить комментарий (/ * ... * /) в сообщение коммита: ->.

Answer 3

Количество полезных битов в исходном файле медленно уменьшается по мере внесения в него изменений с помощью этого оператора $ Log $. У нас это было в некоторых файлах, пришедших из CVS, и число строк в выражениях $ Log $ было в 10 раз длиннее, чем фактически выполняемый код в файле. И у него было несколько групп дубликатов, вызванных плохим слиянием из некоторых ветвей.

Answer 4

Вы можете рассмотреть (выделение может ) встраивание неизменных метаданных в ваш файл.
(См. Спор между мной и «старшей школьницей»: Номера встроенных версий - Хорошо или Зло? ).

Несмотря на то, что я всегда считал эту практику злом (смешивая метаданные с данными), вводя «ад слияния», можно утверждать, что он может работать с правильным менеджером слияния для неизменных метаданных. данные с фиксированным форматом , например:

• $ Revision $ $ Revision: 9.13 $
• $ Дата $ $ Дата: 2009/03/06 06:52:26 $
• $ RCSfile $ $ RCSfile: stderr.c, v $

Но изменяемые метаданные, такие как журналы? С неизвестным форматом или содержанием? Это обязательно потерпит неудачу.