Quando un commit per il controllo di revisione richiede a uno sviluppatore di modificare la propria configurazione

Question

Qual è il metodo migliore per notificare ad altri sviluppatori quando una modifica impegnata nel controllo di revisione richiede un'azione aggiuntiva specifica da parte dello sviluppatore che ottiene l'aggiornamento, ad es. modificare un file di configurazione locale non nel controllo di versione?

Attualmente sto scrivendo nel messaggio di commit, ma sembra che questo potrebbe facilmente essere perso. Qualunque sistema di controllo di revisione fornisce un modo migliore per farlo?

Come fanno le altre persone o non dovrebbero mai esserci modifiche necessarie al di fuori del controllo di revisione?

Sto usando mercuriale ma anche le risposte di chi usa altre forme di controllo di revisione sarebbe utile.

Answer 1

Non ci dovrebbero essere raramente le modifiche necessarie che sono al di fuori del controllo di revisione. Per i rari casi in cui si trovano, utilizzare il normale canale di comunicazione che gli sviluppatori hanno (come mailing list o canale IRC o qualcosa di simile). Ogni progetto multi-sviluppatore ha bisogno di cose del genere comunque.

Answer 2

Solo un'idea, ma si potrebbe avere grilletto sulla base di un modello nel messaggio di commit per inviare una mail con il commento impegnarsi per gli sviluppatori

fattibile con hooks

Answer 3

Personalmente, io uso 2 metodi:

1. la comunicazione uno: dico di altri sviluppatori cosa manipolazioni devono fare per essere up-to-date (corrette, ma a volte, ci manca qualche dettaglio .. ..)
2. lo script: ho creato uno script update che viene utilizzato per gestire l'aggiornamento di tutte le parti del mio progetto (diverse directory, repository diversi, controllo di versione diverso ...), in questo script ho inserito tutti operazione necessaria per mantenere un repository corretto (lo uso per repository svn e git).

Answer 4

con git, quello che si poteva do (anche se in realtà non è lì per questo scenario) è quello di utilizzare un filter driver, purché il commit include le modifiche per un file con un recognizable content (il filtro doesn' t avere un nome o percorso del file).

un driver di filtro è:

• dichiarato in una .gitattributes file (significato, al contrario di ganci o trigger, si può facilmente distribuirlo)
• collegato a uno sbavature e una chiara script (anche versione, la macchia che viene attivata per il commit.
• è possibile, in fase di commit, attivare qualsiasi azione automatica necessaria.

Anche in questo caso, il punto è non utilizzare gli hook (che non è possibile replicare facilmente tra i repository) e utilizzare un meccanismo che può essere versionato e clonato.

Answer 5

Per i file in cui ogni sviluppatore deve apportare modifiche locali (come stringhe di connessione al database, ecc.) Mi piace mantenere un modello come file tracciato, ad esempio localconfig.template.Nei tuoi script di build/avvio potresti avere una logica come questa:

if not exists localconfig then 
    copy localconfig.template to localconfig 
else 
    if localconfig.template is newer than localconfig 
    print a big ugly warning about maybe needing to update