Come deve essere memorizzato il codice nel controllo della versione?

Perché scegliere? Dovrebbe essere entrambi.

Il tuo ambiente di sviluppo deve essere configurato in modo che sia facile come fare un checkout, aprire, costruire, eseguire, eseguire il debug (es: nessun percorso assoluto!). Puoi farlo facilmente con le direttive di compilazione, la classe di configurazione + l'iniezione dipendente, o persino trucchi come il perso.config in ASP.NET

Il tuo script di compilazione automatizzato dovrebbe essere personalizzato in modo tale da occuparsi di specifiche configurazioni di produzione, pulizia, packaging ecc.

Quando si tratta di un progetto open source in cui ci si aspetta che le persone contribuiscano, sceglierei sicuramente lo sviluppatore.

La mia più grande antipatia per i progetti open source è che molto raramente il repository contiene tutte le dipendenze necessarie per costruire il codice (a volte per motivi pratici o legali), ma quando non lo fanno - alcuni non si preoccupano nemmeno di dire tu di quali dipendenze hai bisogno o, cosa più importante, di quale versione hai bisogno. (e preferibilmente dove trovarli)

A volte puoi dedicare più di mezza giornata a recuperare e compilare diversi altri progetti per creare il progetto che cerchi.

Naturalmente, questo è davvero rilevante solo per lo sviluppo su Windows.

Entrambi, ma dipende da quanto frequenti si effettua la produzione. Per molte applicazioni personalizzate, le distribuzioni vengono eseguite manualmente e localmente. D'altra parte, lo sviluppatore impegnerà costantemente il codice, non importa quanto piccolo o grande sia il progetto. Secondo me, è più importante assicurarsi che lo sviluppatore possa utilizzare correttamente il controllo della versione, quindi semplificare la vita in modo che abbiano il tempo di concentrarsi sul codice piuttosto che trovare il modo attraverso il controllo della versione.

Dovrebbe essere favorevole alla produzione, altrimenti è problematico mantenere le build automatizzate.

Sono tutto per abbassare gli attriti in modo che sia più facile portare a termine il lavoro, ma devi anche tener conto delle modalità di errore.

Se la versione del repository di origine è sempre configurata per l'utilizzo in produzione, qual è il risultato di una riconfigurazione dello sviluppatore prima dell'esecuzione del sistema? Uno sviluppatore che esegue codice contro la produzione.

Indipendentemente dal fatto che ci siano altri ostacoli nel modo in cui lo sviluppatore apporta modifiche casuali alla produzione, costruire in una modalità di errore che lo incoraggi a succedere sembra pericoloso.

Suggerisco che i valori predefiniti inclusi nel codice di commit siano sempre sicuri . Controlla anche i file di configurazione di produzione nel controllo del codice sorgente, se vuoi - lo faccio quasi sempre - ma tienili da qualche parte "non live".

Tendo ad impegnarmi per la produzione. Mantiene pulite le tue build e previene la creazione di impostazioni estranee.

Sicuramente sviluppatore amichevole, con script per automatizzare le modifiche per QA & produzione.

Perché non avere un ramo (a seconda del controllo di versione che si usa - io uso Git) per il codice distribuibile e altro per la versione pronta per gli sviluppatori? Questo suona molto meglio e non è così difficile da configurare.

Puoi lavorare e confermare le tue modifiche e quindi unirle nella versione distribuibile.