Devo aggiungere i file .vcxproj.filter al controllo del codice sorgente?

169

Durante la valutazione di Visual Studio 2010 Beta 2, vedo che nella directory convertita, i miei file vcproj sono diventati file vcxproj . Esistono anche file vcxproj.filter accanto a ciascun progetto che sembrano contenere una descrizione della struttura delle cartelle (\ File di origine, \ File di intestazione, ecc.).

Pensi che questi file di filtro debbano essere conservati per utente o dovrebbero essere condivisi in tutto il gruppo di sviluppo e registrati in SCC?

Il mio pensiero attuale è di controllarli, ma mi chiedo se ci sono ragioni per non farlo, o forse buoni motivi per cui dovrei assolutamente controllarli.

L'ovvio vantaggio è che le strutture delle cartelle corrisponderanno se guardo la macchina di qualcun altro, ma forse vorrebbero riorganizzare le cose logicamente?

— jschroedl
fonte

59

Le versioni precedenti di Visual Studio (almeno versioni 6.0 e 2008) memorizzano tali informazioni nel proprio file di progetto (rispettivamente file .dsp e .vcproj), che ovviamente è utile aggiungere a SCC.

Non riesco a pensare a nessun motivo per non includere questi file .filter in SCC

— jrbjazz
fonte

Sono con te. L'ho verificato. Grazie!

— jschroedl,

111

Abbiamo tirato intenzionalmente il filtro. informazioni sui file da .vcproj quando tradotto nel formato MSBuild .vcxproj. Uno dei motivi è esattamente quello che hai sottolineato, che i filtri sono puramente una visione logica e che diversi membri del team potrebbero desiderare viste diverse. L'altro è che a volte la build è impostata per controllare il timestamp del file di progetto e attivare una ricostruzione se è cambiata, perché ciò può significare che ci sono diversi file di origine da costruire o impostazioni diverse, ecc. ricorda se abbiamo effettivamente distribuito la build in questo modo, ma l'idea era che non volevamo attivare una ricostruzione semplicemente perché i filtri sono cambiati, poiché non influiscono sulla build.

— dan moseley
fonte

3

per le ricostruzioni automatiche, costruisci se qualche file è cambiato (es. sorgente), quindi ora nulla è cambiato tranne che abbiamo ancora un altro file da gestire.

— gbjbaanb,

3

Abbiamo finito per registrarli e finora siamo stati contenti di questo accordo. Risulta più bello per noi lavorare con altri sviluppatori se hanno la stessa struttura di filtro.

— jschroedl,

9

Li tratto separatamente. Per quanto mi riguarda, meno merda deve essere preservata come parte dello stato del progetto, meglio è, quindi penso che questa sia una buona decisione.

— rwallace,

6

Possiamo disabilitare del tutto quei filtri se non vogliamo usare alcun albero astratto / logico ma vediamo solo quello del filesystem?

— Johan Boulé,

4

@JohanBoule: sono totalmente d'accordo! Avrebbero dovuto semplicemente scartare i filtri nell'IDE. Esiste già una struttura ad albero logico e si chiama "filesystem". Attualmente ci sono molte duplicazioni: ogni file deve essere aggiunto al filesystem, allo script di build (vcxproj), ai filtri (vcxproj.filters), al controllo del codice sorgente e forse da qualche altra parte. Viola il principio DRY. Fortunatamente sembra che i file di filtro siano opzionali . Puoi semplicemente eliminarli e utilizzare il pulsante "Mostra tutti i file" nell'IDE. Peccato che non sia l'impostazione predefinita.

— Yakov Galka,

5

Ho appena scoperto che se usi Git puoi contrassegnare i file .filter per essere trattati come un sindacato da unire per renderlo più semplice. Basta aggiungere la riga:

*.vcxproj.filters merge=union

al tuo file .gitattributes.

Vedere Utilizzo di .gitattributes per evitare conflitti di unione per maggiori dettagli.

— parsley72
fonte

Il link menzionato non dice che questo file .filters dovrebbe avere "unione" menzionato nel file gitattributes.

— ollydbg23,

2

Ma dice cosa merge=unionfa - nient'altro è stato promesso. Con questa conoscenza e un'idea molto ampia dell'aspetto di * .filter-files, è facile capire perché merge=unionsia una buona idea per quei file.

— Peter Schneider,

1

Non dovrebbe essere aggiunto in caso si utilizza CMake(o simili strumenti di compilazione) per generare file come *.sln, *.vcxproj, *.vcxproj.filtersecc, perché questi file può contenere il percorso completo per la vostra cartella del progetto e altri solo le cartelle specifiche del computer .

— V. Panchenko
fonte