Зачем использовать традиционный подробный 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, требуемый с помощью autotools и «стандартами кодирования GNU».

источник

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

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

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

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

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

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

Answer 1

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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