Зачем поддерживать традиционный подробный ChangeLog в современном мире (с SVN, Mercurial, Git)?

Question

Подробная запись ChangeLog обычно сообщает, кто, когда и какую функцию изменил и почему это изменение было сделано.

И это для каждой отдельной функции в дереве исходного кода!

Как я понимаю ChangeLogпришли из прошлого, когда не было хороших VCS.

Так что традиционный ChangeLog вообще не нужен, так как вы можете получить все это из:

  $ svn log .
  $ hg log .
  $ git log .
  $ bzr log .

Для краткости ChangeLog нужна только одна возможная потребностьСводка между версиями продукта, предназначенная только для пользователя (например, при появлении новой версии разработчик подготовит ChangeLog, чтобы описать заметные / видимые изменения).

Или я ошибаюсь?

От http://autotoolset.sourceforge.net/tutorial.html#SEC45:

The ChangeLog file: Use this file to record all the changes that you make to your
source code. If your source code is distributed among many subdirectories,
and there is reason enough to think of the contents of the subdirectories
as different subpackages,then please maintain a separate `ChangeLog'
file for each subdirectory.

Выглядит архаично и догматично.ChangeLog требуется для автоинструментов и "стандартов кодирования GNU".

Источник GNU Emacs содержит множество огромных ChangeLogs (многие разбиты на множество частей):

  $ find emacs-22.3 -name "ChangeLog*" | xargs cat | wc -c
13605747

Я могу получить сводный журнал изEmacs bzr репо в течение 1 минуты и поиск по нему, вместо этого ищите каждый отдельный ChangeLog и с современными инструментами, такими как Emacs VC или Tortoise SVN/HG, немедленно получите diff для изменений.

UPDATE ОбоснованиеИспользование ChengeLog происходит от тупости системы управления обслуживанием RCS / CVS.Проверьте http://www.red -bean.com / cvs2cl / changelogs.html раздел «Журналы изменений и журнал CVS».Все современные VCS предоставляют / позволяют критиковать эту статью в CVS.

Также существует множество сценариев, которые преобразуют вашу историю VCS в стиль ChangeLog.Так что отклонить все ваши ChangeLog .

Если вы хотите предоставить ориентированную на пользователя информацию о функциях / обратной совместимости / и т.д. между версиями, используйте файл NEWS: http://www.gnu.org/prep/standards/html_node/NEWS-File.html

Answer 1

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

Answer 2

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

Выход журнала из вашей VCS, вероятно, будет более точным.детализированный (т. е. у вас может быть коммит, который помечен как «фиксированные опечатки» - может ли это заинтересовать пользователя?), и он не предоставляет достаточно контекста.Список изменений дает им этот контекст.

Answer 3

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

Answer 4

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

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