Quali argomenti esistono contro l'utilizzo della funzione di sostituzione delle parole chiave in molti sistemi di controllo della versione?

Questo è un artefatto dei vecchi tempi, in cui i file venivano versionati su base individuale (si pensi a RCS, SCCS e CVS) dove i moderni sistemi di controllo delle versioni pensano nei commit atomici e non nei singoli file. Ciò significa che ai vecchi tempi era opportuno tenere traccia a livello di file e il modo migliore per farlo era in un modo che potesse arrivare al codice binario. Quindi parole chiave espandibili che potrebbero andare in stringhe che potrebbero andare nel file oggetto.

In questi giorni, hai un singolo identificatore di commit che deve essere registrato una sola volta per ogni binario e che può essere esplicitamente copiato per andare in un file invece delle parole chiave che espandono il sistema di controllo delle versioni.

Questo è meglio, semplicemente perché significa che le fonti cambiano solo quando TU le modificano.

Ogni sistema di revisione che non può distinguere file di testo da binari è completamente rotto.

Penso che abbiano ragione che non ne hai davvero bisogno; spesso hai bisogno di un modo per mostrare il tuo numero di revisione automaticamente e forniscono un esempio.

Penso che molti altri usi di questa funzionalità siano superflui ma non dannosi.

Può essere fuorviante. Se copio una cartella dal controllo del codice sorgente in un albero separato, quindi la modifica, non avrà più la revisione corretta. Non puoi semplicemente guardare la stringa di revisione estesa per determinare quale versione di un file hai.

Tuttavia, continuo a pensare che siano preziosi. Avere la versione estesa della stringa in un file che si trova all'esterno del sistema di controllo del codice sorgente consente di sapere da dove iniziare la ricerca attraverso la cronologia per determinarne la validità. Mi sono trovato a doverlo fare almeno due volte nell'ultimo mese.