Какие аргументы существуют против использования функции подстановки ключевых слов во многих системах контроля версий?

Какие аргументы существуют против использования функции подстановки ключевых слов во многих системах контроля версий?
Какие аргументы существуют против использования функции подстановки ключевых слов во многих системах контроля версий? - ethanhjy @ Unsplash

Есть ли аргументы против использования функции подстановки ключевых слов (т.е. замены $Revision$ на $Revision: 5$) во многих системах контроля версий? Есть ли какие-либо общие плохие практики, которые поощряет использование этой функции? Есть ли какие-либо повсеместные и трудноразрешимые проблемы, которые она вызывает, когда вы ее используете?

Приведите аргументы против ее использования:

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

Это артефакт старых времен, когда файлы версионировались на индивидуальной основе (вспомните RCS, SCCS и CVS), тогда как современные системы управления версиями мыслят атомарными фиксациями, а не отдельными файлами. Это означает, что в прежние времена имело смысл отслеживать на уровне файлов, и лучший способ сделать это — таким образом, чтобы он мог проникнуть в двоичный код. Отсюда расширяемые ключевые слова, которые могут быть в строках, которые могут быть в объектном файле.

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

Это лучше просто потому, что это означает, что источники меняются только тогда, когда ВЫ их редактируете.


LetsCodeIt, 25 мая 2023 г., 09:28