Come gestite i file .vcproj nel controllo del codice sorgente che vengono modificati da più sviluppatori?

Question

Usiamo Subversion come nostro sistema di controllo del codice sorgente e memorizziamo i file di progetto di VisualStudio (vcproj) nel sistema di controllo del codice sorgente, secondo me è normale. Con Subversion non utilizziamo alcuna forma di blocco dei file, quindi se due sviluppatori stanno lavorando allo stesso progetto contemporaneamente ed entrambi aggiungono file al progetto o cambiano le impostazioni, il secondo da impegnare deve unire le modifiche.

Come unisci queste modifiche?

I file vcproj sono solo file di testo, quindi è possibile modificarli a mano ma non sono molto adatti alla modifica manuale, specialmente da parte di sviluppatori junior.

I modi in cui riesco a pensare sono

• Ottieni l'ultima versione da svn e aggiungi nuovamente tutte le modifiche locali manualmente
• Modifica il file a mano per risolvere eventuali conflitti da un'unione automatica
• Implementa una qualche forma di schema di blocco per prevenire modifiche simultanee
• Accordo tra gli sviluppatori in modo che non apportino modifiche simultanee

Attualmente stiamo utilizzando la prima opzione per aggiungere nuovamente tutte le modifiche manualmente, ma ciò richiede tempo e mi chiedevo se esiste un modo migliore.

Con i file di origine la funzione di unione automatica funziona la maggior parte delle volte e non ci sono molti conflitti.

Answer 1

Ho trovato che l'opzione 2 (modifica i file a mano) generalmente funziona abbastanza bene, purché tu stia usando un buon strumento diff (io uso WinMerge ). Il problema principale che ho riscontrato è che Visual Studio a volte riordina il file. Ma se hai un buon strumento diff / merge allora dovrebbe essere in grado di distinguere tra contenuto modificato e contenuto spostato. Questo può aiutare molto.

Answer 2

Potresti trovare Progetto: Unisci o Strumenti per il file SLN utile

Answer 3

Questo è un problema difficile e penso che sia un punto debole nell'architettura di Visual Studio. Il modo in cui lo abbiamo trovato era di non avere affatto i file proj nel controllo del codice sorgente e di avere uno script di build che gestisse le impostazioni di configurazione.

L'alternativa era molto disordinata e non potevamo garantire build o ambienti coerenti tra gli sviluppatori. Ciò ha portato a un numero enorme di problemi di integrazione a valle e alla fine abbiamo fatto il passo draconiano di rimuovere i file di progetto dal controllo del codice sorgente.

Gli ambienti degli sviluppatori potrebbero ancora non essere allineati, ma è apparso quando hanno provato a costruire le cose da soli.

Answer 4

Usando TFS qui, ma non penso che faccia la differenza.
Inoltre, non blocciamo, e talvolta dobbiamo fare i conti con l'unione dei file di progetto. Non ho mai trovato che fosse un problema così complesso o molto. Raramente abbiamo mai riscontrato problemi che non possono essere uniti automaticamente e il processo di unione manuale è praticamente banale.

C'è solo un avvertimento: controlla spesso! Se si apportano modifiche sostanziali alla struttura del progetto e non le si registra immediatamente, tali modifiche possono iniziare a complicare la complessità delle fusioni successive. Se apporto una modifica sostanziale alla struttura di un progetto, di solito do un avvertimento a tutti. Chiederò a tutti di controllare il loro lavoro attuale, e poi mi occuperò personalmente della fusione.

Answer 5

L'ho trovato di recente: http://www.codeproject.com/KB/macros /vcproj_formatter.aspx Se esegui questo strumento su un file vcproj e su una versione modificata di esso, puoi unirli facilmente insieme al tuo strumento di unione testo preferito e inoltre il risultato è un file vcproj piuttosto compatto.

Answer 6

Le opzioni 1 e 2 non si escludono a vicenda: se lo sviluppatore è di livello junior, lascia che utilizzino l'opzione 1 (ottieni nuovamente il file di progetto e rifai le modifiche) se è più comodo per loro. Per gli sviluppatori più senior, l'opzione 2 (unione mediante uno strumento di unione) va perfettamente bene.

Penso che questa sia una situazione che attualmente non ha proiettili magici - a volte la fusione è un dolore.

Answer 7

Utilizziamo uno strumento diff ( WinMerge ) per unire le modifiche. I file di progetto sono (per la maggior parte) XML davvero diretti. La chiave qui, però, è che non ci dovrebbero mai essere sorprese quando si fondono, perché una buona comunicazione fa parte della base di un efficace controllo delle fonti.

Le modifiche simultanee al progetto vanno benissimo fintanto che le persone comunicano.