Come faccio a sapere se una particolare build ha una particolare variazione di controllo della versione?

La maggior parte dei sistemi di controllo delle modifiche identifica in modo univoco ogni modifica / commit / check-in. Ad esempio, subversion ha l'ID di revisione e git ha l'hash del commit. Un ramo / tag per ogni versione o registra l'identificativo del commit. In alternativa, tieni traccia di un numero di build nel codice sorgente e cerca nella cronologia / log una versione con quel numero di versione. Con questo, uno sviluppatore può trovare la versione nel sistema di controllo del codice sorgente e controllare i commit precedenti per determinare quali modifiche sono presenti in un rilascio.

Non memorizzare la lista delle modifiche nel file binario. Questo di solito deve essere aggiornato manualmente e, quindi, è soggetto a omissioni accidentali o errori di copia e incolla. Anche la lista delle modifiche potrebbe diventare grande. Quanto fa indietro la lista delle modifiche? Quante informazioni sono incluse in ogni cambiamento? È solo un numero del problema dal sistema di tracciamento dei problemi o di tracciamento delle modifiche o ci sono più informazioni? Infine, inserire queste informazioni nel file binario può aiutare un utente malintenzionato a trovare vulnerabilità di sicurezza nel prodotto.

Per quanto riguarda cosa taggare, taggalo con il numero di versione della versione. Se la release è una tantum, come quella che contiene una modifica specifica per un cliente di grandi dimensioni, aggiungi l'ID della richiesta nel sistema di supporto o emetti il sistema di tracciamento.

Il sistema operativo (Mac o Windows) di solito non è rilevante.

2) Tag version control using some string that uniquely identifies that build. What unique string would I use?

Stai usando un sistema di tracciamento dei bug?

Se non suggerisco JIRA o Mantis (Preferisco JIRA personalmente, ma ho anche lavorato con Mantis prima e sebbene non fosse bello come JIRA, andava bene)

Che si tratti di un bug o di un'evoluzione, gli sviluppatori dovrebbero avere assegnato un ticket di errore. Il ticket bug ha un nome univoco (ad esempio PROJECTX-234). Comunicare a tutti gli sviluppatori che il loro commento deve contenere il nome del biglietto a cui si riferisce la modifica. Ciò consentirà di recuperare nel repository di origine tutto ciò che è correlato a una determinata modifica nell'applicazione. La ricerca con l'aiuto dei commenti dovrebbe portare a un elenco simile a questo:

 PROJECTX-234 first commit
 PROJECTX-234 yyy
 ...
 PROJECTX-234 xxx 

Inoltre, JIRA stesso e diversi strumenti di sviluppo continuo (come ad esempio Jenkins ) possono connettersi direttamente al tuo repository in modo che la bugcard è "collegata" al codice che è stato modificato per risolverlo.

Non so quale sia il tuo strumento di compilazione, ma ad esempio Jenkins elencherà una determinata build o rilascerà le modifiche che si sono verificate. Inoltre, se si aggiunge il plugin JIRA, Jenkins può scrivere un commento direttamente nel ticket del bug per indicare in quale build il bug è stato risolto.

Infine, se non vuoi lavorare con un sistema di tracciamento dei bug, scrivi un semplice file Excel con i compiti che devi eseguire e scegli un nome univoco per ognuno. Usa quel nome univoco nei tuoi commit.

Non lo facciamo nella mia attuale compagnia, e non posso davvero dire di aver perso questa funzione, ma nella mia precedente società abbiamo fatto la tua opzione (1) aggiungendo ad ogni file sorgente:

static const char* fileId = "$Id: $";

La maggior parte dei sistemi di controllo di revisione supporta un qualche tipo di tag che viene automaticamente compilato quando il file viene archiviato, quindi non appena il file entrerà nel controllo del codice sorgente, quel tag verrà automaticamente modificato in:

static const char* fileId = "$Id: Utility.cpp; rev 6; last check-in 5/2/2012 by so-and-so $";

Il formato della stringa è costituito dal fatto che non ricordo realmente come appariva, ma hai un'idea. Quando un file binario è stato creato da questi file di origine, puoi sempre eseguire

strings app_name | grep Utility.cpp

Questo ti darebbe la revisione esatta di Utility.cpp che è andata a costruire quel binario. (Sono passati anche 8 anni da quando ho toccato la riga di comando di unix, quindi per favore non tenerlo contro di me se non avessi esattamente la riga di comando, l'idea è lì).

Mentre potremmo certamente farlo nella società per cui lavoro per ora, penso che non abbiamo mai avuto bisogno di questa tecnica semplicemente perché una volta che si ottiene un processo di costruzione stabile e affidabile, si può semplicemente dare un'occhiata al numero di versione del file binario e sai esattamente quali sono state le revisioni dei file per farlo.