File .filter VS2010 e SVN

Question

Da quando siamo passati a VS2010 abbiamo notato un nuovo file .filters che apparentemente contiene la struttura del filtro del progetto. Stiamo anche utilizzando la sovversione come nostro controllo del codice sorgente.

Sfortunatamente, ogni volta che effettuiamo il check-in, ci ritroveremo con conflitti di unione se qualcuno ha aggiunto un file o un filtro al progetto. SVN sembra assolutamente incapace di unire correttamente questo tipo di file anche se è basato sul testo. Sta diventando piuttosto frustrante.

Qualcun altro si occupa di questo problema? Qualcuno ha trovato una soluzione?

Esempio di conflitto, il codificatore 'a' aggiunge any.txt e controlla, il coder 'b' aggiunge il filtro e il nuovo file .cpp e gli aggiornamenti. Ottiene questo:

<?xml version="1.0" encoding="utf-8"?> 
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> 
    <ItemGroup> 
    <Filter Include="filter_1"> 
     <UniqueIdentifier>{065f6d5d-81b2-4c98-b313-dceb16c24bf2}</UniqueIdentifier> 
    </Filter> 
    <Filter Include="filter_2"> 
     <UniqueIdentifier>{85ef5151-d045-4b20-b1bf-e65d380a3cf3}</UniqueIdentifier> 
    </Filter> 
    <Filter Include="filter_2\sub_filter_1"> 
     <UniqueIdentifier>{90efdbe3-b53a-41fc-9dfb-147df5e7d7f3}</UniqueIdentifier> 
    </Filter> 
    <Filter Include="NewFilter1"> 
     <UniqueIdentifier>{8162b584-12a0-4a05-8cc5-ede4ced07ba3}</UniqueIdentifier> 
    </Filter> 
    </ItemGroup> 
    <ItemGroup> 
    <ClInclude Include="filter_2\file_3.hpp"> 
     <Filter>filter_2</Filter> 
    </ClInclude> 
    <ClInclude Include="filter_2\sub_filter_1\file_4.hpp"> 
     <Filter>filter_2\sub_filter_1</Filter> 
    </ClInclude> 
    <ClInclude Include="filter_1\file_1.hpp"> 
     <Filter>filter_1</Filter> 
    </ClInclude> 
    <ClInclude Include="filter_1\file_2.hpp"> 
     <Filter>filter_1</Filter> 
    </ClInclude> 
    </ItemGroup> 
<<<<<<< .mine 
    <ItemGroup> 
    <ClCompile Include="whatnot.cpp"> 
     <Filter>NewFilter1</Filter> 
    </ClCompile> 
    </ItemGroup> 
======= 
    <ItemGroup> 
    <None Include="whatever.txt" /> 
    </ItemGroup> 
>>>>>>> .r12513 
</Project> 

Answer 1

sono semplici file XML come gli altri file di progetto in studio visivo - non vedo perché dovrebbero essere qualsiasi più suscettibili di conflitti di altri file di progetto.

Questi file possono essere trattati come binari e non come testo? L'unione di file binari non funzionerà: controlla le proprietà svn per vedere a quale tipo di mime sono impostati (se non è impostato alcun tipo mime, dovresti stare bene). Se il tipo mime è impostato, è possibile che tu abbia a che fare con un automatic property errato.

Infine, è possibile che le persone aggiungano e rimuovano costantemente i file. In tal caso, potrebbe essere necessario eseguire il commit e l'aggiornamento più frequentemente fino a quando il progetto non si stabilizzerà un po 'di più.

Non si dovrebbe assolutamente svn:ignore questi file.

Answer 2

Se il file ".filters" è qualcosa di specifico per la configurazione dell'utente, allora probabilmente non appartiene a Subversion a tutti. È possibile effettuare Subversion ignorare le modifiche al file utilizzando lo svn: ignore:

 
svn propset svn:ignore '.filters' . 

Il comando sopra farà Subversion iniziare ignorando le modifiche al file denominato ".filters".

Un'altra opzione è quella di forzare Subversion per trattare il file ".filters" come un file binario:

 
svn propset svn:mime-type 'application/octet-stream' .filters 

Il comando sopra farà sì che il file ".filters" di essere trattato come un file binario e volontà non essere uniti.

Modifica
Ora che hai spiegato che il file ".filters" è fondamentale per il progetto e, inoltre, che il problema potrebbe essere che viene trattato come binario anziché come testo normale, la soluzione è per impostare il tipo di testo in chiaro:

svn propset svn:mime-type 'text/plain' .filters 

Answer 3

ti offro questo in relazione alla finalità del file .vcxproj.filters:

Quando creo un progetto C++ con Visual Studio 2010, versione 10.0.40219.1 SP1Rel, genera un file chiamato ReadMe.txt nella cartella del progetto che include questo testo:

<YourProjectName>.vcxproj.filters 
    This is the filters file for VC++ projects generated using an Application Wizard. 
    It contains information about the association between the files in your project 
    and the filters. This association is used in the IDE to show grouping of files with 
    similar extensions under a specific node (for e.g. ".cpp" files are associated with the 
    "Source Files" filter). 

Così, in effetti, questo conferma che il file .vcxproj.filters governa la struttura di cartelle che si vede in Esplora soluzioni.

Answer 4

Stiamo vivendo lo stesso problema. Non ha nulla a che fare con il fatto che non vengano uniti correttamente a causa dello stato testo/binario, ma piuttosto a causa di una stranezza della fusione di SVN.

In genere se una persona aggiunge un nuovo file al progetto e si impegna quindi il diff sarà qualcosa del tipo:

<ClCompile Include="dir1\newfile1"> 
     <Filter>dir1</Filter> 
    </ClCompile> 

Nel frattempo, utente2 aggiunge un nuovo file per lo stesso filtro (cioè il nodo della cartella nella albero di soluzione):

<ClCompile Include="dir1\newfile2"> 
     <Filter>dir1</Filter> 
    </ClCompile> 

Quando gli aggiornamenti user2 che otterranno un conflitto

<<<<< 
    <ClCompile Include="dir1\newfile1"> 
    ===== 
    <ClCompile Include="dir1\newfile2"> 
    >>>>>> 
     <Filter>dir1</Filter> 
    </ClCompile> 

La cosa fondamentale è come si risolve il conflitto. Se si utilizza il 'Usare A allora B' opzione del vostro strumento di unione, allora si finirà con questo:

<ClCompile Include="dir1\newfile1"> 
    <ClCompile Include="dir1\newfile2"> 
     <Filter>dir1</Filter> 
    </ClCompile> 

che è XML non valido. Sfortunatamente VisualStudio non sembra sempre lamentarsi di questo (anche se di solito lo fa - sembra dipendere dalla natura precisa del cambiamento). Così si può poi finire con alcuni file orfani dai propri filtri - credo che in questo caso si cercherà di risolvere il problema da finire il primo <CLCompile>:

<ClCompile Include="dir1\newfile1" /> 

Questo significa allora che apparirà newfile1 in alto livello del progetto piuttosto che nel filtro dir1. Dopo aver visualizzato alcuni nodi non validi sembra che inizierai a ottenere più conflitti finché qualcuno non risolve il progetto.

Quindi, la soluzione a tutto questo è che è necessario rendere gli utenti consapevoli della struttura del file quando risolvono i conflitti, non solo affidarsi ciecamente allo strumento di fusione. Devi assicurarti che ogni voce abbia tutte e 3 le linee: l'apertura <CLCompile> o <CLInclude>, il filtro e il tag di fine.

Questo intero problema esiste solo a causa di una stranezza dell'XML in quanto un conflitto interesserà solo una o due delle tre linee. Se il tag di chiusura XML si trovava sulla stessa riga del filtro, non sarebbe successo.