Visual Studio, svn e unione di file .csproj e .sln

Question

Chiunque ha avuto successo nell'ottenere SVN per unire file di progetto Visual (.csproj) o soluzione (.sln) che sono stati modificati da due utenti? Esempio

1. utente A estrae progetto
2. utente B estrae stesso progetto
3. utente A aggiunge un file
4. utente A si impegna modifiche
5. utente B aggiunge un file
6. utente B si impegna modifiche

Mi sembra che al punto (6), svn, tartaruga, Ankh o qualunque cosa dovrebbe de risolvere un conflitto e unire i due file di progetto automaticamente o, più probabilmente, richiedere all'utente B di risolvere il conflitto. Al momento, stiamo vedendo le modifiche apportate dall'Utente A cancellate quando l'Utente B effettua il check-in, con conseguenti cattive build, distribuzioni, ecc. Funzionalità mancanti che erano state aggiunte prima dell'ultimo check-in.

Poiché i file di progetto sono XML, perché questo è un problema? Mi sto perdendo qualcosa qui? Ho cercato qui gli archivi e ho cercato su Google Non riesco più a google, ma non ho trovato una buona soluzione.

Answer 1

Come pensi di indurre SVN a eseguire il passaggio n. 6? Sembra che tu abbia frainteso ciò che va storto. SVN non commetterà mai da una copia di lavoro non aggiornata, pertanto il passaggio 6 non funzionerà senza che l'utente B in precedenza abbia aggiornato e unito le modifiche dell'utente A. Onestamente. Provalo.

Credo che quello che succede invece è questo:

1. Un estrae progetto.
2. B verifica lo stesso progetto.
3. A aggiunge un file.
4. Un commit cambia.
5. B aggiunge un file, ma si dimentica di salvare il progetto/la soluzione.
6. B tenta di eseguire il commit delle modifiche e riceve un messaggio che deve aggiornare per primo.
7. aggiornamenti B.
8. B torna a VS. VS gli dice che il progetto/soluzione è cambiato su disco e chiede se vuole a) ricaricare dal disco e perdere le sue modifiche b) sovrascrivere la versione su disco.
9. B non capisce, non cerca di capire, considera le sue modifiche importanti e seleziona b), ignorando le modifiche sul disco.
10. B ancora non tenta di capire e quindi non diff la versione che ha su disco con l'ultimo commesso e quindi manca che ha annullato le modifiche di A.
11. B Effettua il check-in, ignorando le modifiche di A.

Ho visto accadere una volta ogni tanto, di solito con un utente B che non capisce il flusso di lavoro di SVN (o CVS ', FTM).

Quindi, ecco alcuni suggerimenti:

Non aggiornare se non si è salvato tutto ("File" -> "Salva tutto", per me, questo è Ctrl + Maiusc + S). Se hai commesso questo errore e sei bloccato, ignora le modifiche sul disco e quindi unisci manualmente le modifiche perse. (Potrebbe anche funzionare per aggiornare nuovamente il file di progetto/soluzione alla versione N-1 e poi a HEAD, per fare in modo che SVN esegua l'unione.)

Non eseguire il commit senza controllare quali file si modificato e con un rapido guarda le differenze per vedere se le modifiche sono quelle che ti aspetti.

Impegnarsi in anticipo, commettere spesso. Più gli sviluppatori lavorano sulla stessa base di codice, più è probabile che si verifichino conflitti. Più a lungo cambi la tua copia di lavoro senza aggiornare, più è probabile che tu abbia dei conflitti. Poiché il numero di sviluppatori di solito è fuori mano, la frequenza di aggiornamento è l'unica cosa che puoi usare per ridurre la probabilità di conflitti.

Answer 2

Una soluzione piuttosto radicale ma efficiente consiste nell'utilizzare uno strumento per generare quei file di soluzione da una meta-definizione e quindi inserire solo la meta-definizione sotto il controllo del codice sorgente, non i file di progetto di Visual Studio (che sono un incubo da unire) .

Nel mio team usiamo MPC per fare questo. Abbiamo:

• un gruppo di file .mpc per descrizioni dei progetti,
• un file .mwc per la descrizione di lavoro/soluzione,
• un piccolo .cmd per generare file di Visual Studio.

Dato che sono tutti file di testo modificati a mano, non abbiamo più problemi con Visual Studio che confonde tutto.

Gli svantaggi sono un extra-strumento e la necessità di rigenerare i file della soluzione quando vengono aggiunti o rimossi i file, ma ci sono alcuni vantaggi aggiuntivi troppo:

• configurazioni di progetto sono centralizzati: per esempio, la modifica di una compilation flag viene eseguito in un singolo posto anziché su base per progetto,
• questo può ospitare più sistemi di build (attualmente utilizziamo Visual 2003 e 2005 ma funziona anche con gcc e altri).

Dalla mia esperienza, la creazione di uno strumento può essere un po 'doloroso (ma tutto dipende dalle dimensioni e dalla complessità del progetto), ne vale la pena.

Si noti che MPC non è l'unico strumento per questo scopo. Esistono altri, come ad esempio CMake.

Answer 3

I seconda risposta di sbi. Una possibile soluzione è di aggiornare sempre da Visual Studio, almeno se si utilizza VisualSVN (non sono sicuro di come AnkhSVN affronta questa situazione).

VisualSVN bloccherà visual studio durante l'operazione di aggiornamento e si assicurerà che tutti i progetti modificati vengano ricaricati automaticamente, in modo che gli utenti non possano ignorare le modifiche esterne.

Answer 4

Si può anche provare a ridurre i conflitti assicurandosi che i file di progetto non elencino ogni singolo file all'interno del progetto. Ciò eviterà che il file di progetto venga modificato al primo posto quando un utente aggiunge un file.

Sei libero di utilizzare i caratteri jolly all'interno di un file di progetto: see MSDN

Esempio:

<ItemGroup> 
    <Compile Include="Src\**\*.cs" /> 
    [...] 
</ItemGroup> 

E 'triste che Visual Studio non incoraggia questo tipo di configurazione di progetto e invece opta per la quotazione singoli file.

Answer 5

Questo è molto noioso e noioso, quindi devi solo attraversarlo. A volte manterrai la copia di lavoro locale poiché ha tutti i tuoi progetti personalizzati aggiunti. Tuttavia, in altri casi, si desidera unire tutti i nuovi elementi dalla soluzione di base in modo da ottenere tutto da entrambi i file di soluzione. Per motivi di leggibilità, è meglio posizionare tutte le aggiunte di prodotti di base prima delle aggiunte alla personalizzazione.

Non preoccuparti che la prima parte del GUID sia identica per i progetti, ma è l'ultima porzione che sarà unica.

Fissh