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

Question

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

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

Answer 1

Позвольте системе управления версиями справиться с этим.

Если вы разместите детали изменения в заголовке, это вскоре станет громоздким и перегружает сам код.

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

Answer 2

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

Answer 3

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

Answer 4

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

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

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

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

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

Answer 5

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

Answer 6

Еще один голос за то, чтобы позволить системе SCM обрабатывать комментарии при проверке, но я хочу кое-что добавить.

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

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

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

Answer 7

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

Answer 8

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