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

Question

По крайней мере два блестящих программиста, Линус Торвальдс и Гвидо фон Россум, пренебрегают практикой помещения ключевых слов в файл, который раскрывается для отображения номера версии, последнего автора и т. Д.

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

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

Существует также проблема «откуда сделал этот файл», возникающая, когда поспешный разработчик копирует файл из одного места в другое, используя файловую систему, а не извлекает его из хранилища с помощью инструмента; или, что более оправданно, когда файлы, находящиеся под контролем в местоположениях A, B и C, необходимо маршалировать (с выбором вишни) в место распространения D.

Как вы справляетесь там, где запрещены ключевые слова VCS?

Answer 1

Я никогда не использовал ключевые слова VCS за всю свою карьеру, более 30 лет. От самой примитивной системы VCS, которую я использовал, до настоящего времени (TFS) я использовал некоторую другую структуру, чтобы понять «где я».

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

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

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

Answer 2

Это не совсем отвечает на ваш вопрос, но я думаю, что у Линуса и Гвидо есть причины не любить ключевые слова, которые не относятся к корпоративному развитию небольшой команды.

Например, тег $Id$ содержит то, что вы можете считать глобальным номером версии. Linux и я полагаю также, что разработка Python достаточно фрагментирована, поэтому ни одно число не может быть глобальным. У многих людей есть свои собственные репозитории повсюду, которые будут заполнять их собственные значения $Id$, и затем эти патчи могут быть отправлены в репозитории Линуса или Гвидо, где они не имеют никакого смысла.

Однако в вашей среде у вас, вероятно, есть один центральный репозиторий, который бы их назначал, и это было бы хорошо. Похоже, вы используете Git. Интересно, возможно ли настроить центральный репозиторий git для подстановки тегов, а локальные репозитории разработчиков - нет. Или, возможно, лучше получить хеш коммита в теге.