Perché mantenere il ChangeLog dettagliato tradizionale nel mondo moderno (con SVN, Mercurial, Git)?

Question

La voce dettagliata di ChangeLog indica di solito chi, quando e quale funzione è stata modificata e per quale motivo questa modifica è stata eseguita.

E questo per ogni funzione separata nell'albero del codice sorgente!

Come ho capito, ChangeLog viene dal passato quando non c'erano buoni VCS.

ChangeLog così tradizionale non ha bisogno affatto come si può ottenere tutto da:

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

solo una possibile necessità di changelog per breve sintesi tra le versioni del prodotto e destinato per l'utente solo (ad esempio, quando nuova versione, lo sviluppatore prepara ChangeLog descrive cambiamenti notevoli/visibili).

O mi sbaglio?

Da 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. 

sguardo arcaica e dogmatica. ChangeLog richiesto dagli autotools e da "GNU coding standards".

GNU Emacs sorgente contiene un sacco di enormi ChangeLog (molti diviso da molte parti):

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

posso ottenere registro di riepilogo da Emacs bzr pronti contro termine per circa 1 min e la ricerca in esso, invece di ricerca per ogni separata ChangeLog e con strumenti moderni come Emacs VC o Tortoise SVN/HG ottiene immediatamente la differenza per la modifica.

AGGIORNAMENTO Le motivazioni per l'utilizzo di ChengeLog derivano dall'impotenza del sistema di controllo servoassistito RCS/CVS. Controllare la sezione http://www.red-bean.com/cvs2cl/changelogs.html "ChangeLogs e il registro CVS". Tutti i VCS moderni forniscono/consentono di criticare questo articolo in CVS.

Esistono anche molti sctipts che convertono la cronologia VCS in stile ChangeLog. Quindi rifiuta tutti i tuoi ChangeLog s.

Se si desidera fornire orientato all'utente informazioni di caratteristiche/compatibilità di nuovo/etc tra le versioni utilizzano file NEWS: http://www.gnu.org/prep/standards/html_node/NEWS-File.html

Answer 1

Con VCS distribuito, è diventato uno standard di "Commit Early, Commit Often". Con tale approccio, si avranno più commit di quelli che si hanno nuove funzionalità o correzioni di bug. Il changelog dovrebbe riassumere le modifiche all'intera applicazione. Il registro VCS d'altra parte mostra la cronologia del codice sorgente, cioè come è stata implementata la funzionalità.

Answer 2

Come dici tu, un registro delle modifiche gestito manualmente può essere utile come un riepilogo delle modifiche visibili dall'utente, o come una panoramica dei cambiamenti su larga scala che potrebbero essere difficili da determinare guardando un sacco di singoli messaggi di commit.

Answer 3

Un log delle modifiche è utile per le persone che non sono sviluppatori e cercano di ottenere un'immagine più ampia di ciò che è cambiato. Mentre un log delle modifiche può essere dettagliato, non mi aspetto che un utente di qualsiasi applicazione che ho scritto vada attraverso l'output git log per capire cosa è cambiato.

È probabile che l'output del registro del VCS sia più dettagliato (vale a dire che è possibile che un commit sia contrassegnato con "errori di battitura fissi" - è probabile che l'utente si interessi?) E non fornisca un contesto sufficiente. Il registro delle modifiche fornisce loro quel contesto.

Answer 4

In aggiunta ai tuoi motivi (solo utente, ecc.), Penso che possano essere molto utili durante lo sviluppo. Spesso eseguo un paio di modifiche prima di eseguire il controllo del codice sorgente e le annoterò nel registro delle modifiche mentre lavoro.

Inoltre, se le modifiche vengono apportate e quindi rimosse, potrebbe essere più difficile selezionare un registro di revisione del controllo sorgente di un singolo file (ad esempio, eliminare una riga). Come nota a margine, tendo a mantenere il mio registro delle modifiche sotto il controllo del codice sorgente oltre al mio codice sorgente.