Effettuate il check in bin o cartelle di debug (e dll) nel vostro TFS?

Domanda veloce su TFS - Ragazzi check-in bin / debug cartelle in TFS? (in tal caso, perché?) Dato che il contenuto di tali cartelle è generato dinamicamente, è meglio lasciarle fuori in modo che il programmatore non si imbatta in problemi di sola lettura?

Come regola generale, il controllo del codice sorgente viene utilizzato esclusivamente per il codice sorgente e i file generati non sono file sorgente.

Ci sono eccezioni A volte (usando Visual Studio) potresti voler conservare il file .pdb per leggere i minidump. A volte non è possibile duplicare una toolchain, in modo da non poter necessariamente ricreare con precisione i file generati. In questi casi, sei principalmente interessato a farlo per il software rilasciato, non per ogni modifica di VCS, e in ogni caso questi possono risiedere facilmente in cartelle con versione. (Questi sono in genere file binari, comunque, e non hanno cambiamenti comprensibili da una versione all'altra e non traggono molto beneficio dall'essere in un VCS.)

Semplice risposta? No. Non farlo! Non riesco a pensare a molte ragioni per non farlo, ma nessuna ragione per cui vorresti farlo.

L'unica volta in cui posso pensare che verrai registrato in una DLL è se proviene da una libreria di terze parti che non ti aspetti che tutti gli sviluppatori abbiano installato per costruire. Ma ancora, non si trova nella cartella bin.

Detto questo, ho lavorato in un'azienda che richiedeva che ogni pacchetto di distribuzione fosse sottoposto al controllo del codice sorgente, ma era così che potevamo tracciare le varie build che avevamo dato al nostro cliente e, se necessario, potevamo facilmente tornare indietro.

Non controlliamo nella cartella bin in TFS. Come probabilmente avrai notato, se lo fai, ogni volta che uno sviluppatore crea la soluzione, controllerà la cartella bin. Non bene. Tuttavia ci sono librerie di cui il progetto ha bisogno per compilare ed eseguire, e la nostra regola è che qualsiasi progetto dovrebbe essere in grado di essere aperto dal controllo del codice sorgente, e dovrebbe essere compilato ed eseguito. Quindi, ciò che facciamo è creare una cartella "BinRef" per qualsiasi DLL a cui il progetto deve fare riferimento e creare i riferimenti del progetto alla copia nella cartella BinRef. La cartella BinRef è archiviata in TFS.

L'altro vantaggio di questo approccio è che BinRef è sempre al livello principale del progetto Web. Se il mio progetto vive C:\Projects\Marcie\SomeProjectCategory\ProjectAe creo un riferimento a una DLL che si trova in C:\DLLsThatILike, il riferimento finirà per apparire qualcosa di simile

\..\..\..\NiceThing.dll

. Puoi conservare i tuoi file di progetto, il C:\ProjectAche significa che il riferimento al progetto NiceThing esploderà sul tuo computer. Spero che le persone non stiano facendo riferimenti in questo modo, ma l'ho visto accadere.

Effettuiamo il check-in dei contenuti delle directory bin come parte del nostro processo di richiesta di modifica. Per evitare problemi di sola lettura, copiamo i contenuti in una cartella separata e li registriamo da lì. La nostra politica aziendale richiede che tutti i file binari che vanno alla produzione siano archiviati separatamente dalla fonte. Non è la soluzione migliore ma funziona e ci dà i file esatti che sono in produzione.

Esito a controllare qualsiasi file non testuale nel controllo del codice sorgente. Soprattutto quelli che dovrebbero essere generati dallo sviluppatore. Mi piace anche mantenere altri file binari, come immagini e PDF, compressi e archiviati altrove per ogni tag / rilascio.

No, ma il nostro strumento di controllo del progetto interno fa automaticamente, il che mi dà fastidio.

La mia soluzione è quella di contrassegnare tutti i file in versione e debug come scrivibili e quando TFS si lamenta gli dico di ignorare i file, quindi non ho mai un problema con un errore di compilazione.

Evito di inserirli nel controllo del codice sorgente. Sono informazioni ridondanti, i binari possono essere creati dal codice sorgente in quella revisione. Inoltre, il codice sorgente è sempre aggiornato, le build potrebbero non essere in commit.

Salvo alcuni file binari generati, come interoper .NET da un altro progetto. Quindi, se ho un progetto A che crea un oggetto COM, e quindi usi quell'oggetto COM in un progetto B molto vagamente correlato che lo utilizza tramite l'interoperabilità .NET, controllo quell'interoperabilità generata dal progetto A nel progetto B. È non è una buona idea, ma deve andare da qualche parte perché AFAIK Visual Studio non creerà l'interoperabilità automatica durante la compilazione.

Secondo me, non memorizzare i binari nel controllo del codice sorgente è uno degli errori più comuni. Dovrebbero essere archiviati, versioni, baselined / etichettati insieme alle fonti e anche strumenti di costruzione. Suite te stesso con la creazione di software non tracciabile ...