История файла: в источнике или пусть scm справится с этим?

Question

Я изучаю Mercurial в качестве моего сольного программного обеспечения SCM. С помощью другого программного обеспечения для управления вы можете помещать комментарии изменений в заголовок файла с помощью тегов. С hg вы комментируете набор изменений, и это не попадает в источник. Я больше привык к центральному управлению, как VSS.

Зачем мне помещать историю файлов в заголовок исходного файла? Должен ли я позволить Mercurial управлять историей с моими комментариями ревизий?

Answer 1

Пусть система управления исходным кодом справится с этим.

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

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

Answer 2

Разница не в том, централизованная или распределенная VCS, а в том, что меняется.

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

Если мне когда-либо понадобится идентифицировать все изменения для конкретного изменения, я могу различаться между двумя версиями проекта.

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

(Как побочный эффект, я обнаружил, что мои комментарии к описанию процесса стали лучше)

Answer 3

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

Answer 4

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

Answer 5

Еще один голос за то, что система СКМ обработала комментарии о регистрации, но мне есть что добавить.

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

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

Но это просто комментарий, который вы говорите! Правда, но у меня действительно был случай, когда в моем исходном файле был код, который, как ни странно, имел причину выглядеть как тег заголовка RCS, и этот фрагмент кода заменялся при регистрации, тем самым портя мой код. Достаточно легко исправить, но плохо, что сборка сломалась для 20+ пользователей

Answer 6

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

Answer 7

Гораздо проще забыть вести историю в источнике, так как всегда (imo) следует комментировать коммиты в систему контроля версий, которая устраняет проблему. Также, если изменение большого количества файлов перед фиксацией, изменение истории в каждом файле будет раздражающей работой. Это действительно один из моментов, когда у вас есть scm.

Answer 8

У меня есть опыт с этим. У меня была история файлов в комментариях, это было ужасно . Ничего, кроме мусора, иногда вам придется пролистывать почти 1 тыс. Строк изменений кода, прежде чем вы, наконец, получите то, что хотели. Не говоря уже о том, что вы замедляете другие аспекты процесса сборки, добавляя больше килобайт в дерево исходного кода.