VS2010 .filter文件和SVN

由於我們切換到VS2010，我們注意到一個新的.filters文件，它明顯包含項目的過濾器結構。我們也使用顛覆作爲我們的源代碼控制。VS2010 .filter文件和SVN

不幸的是，我們每次在檢查的時間，現在我們最終合併衝突如果任何人添加的文件或過濾器項目。即使它是基於文本的，SVN似乎也無法正確地合併這種文件類型。它變得相當令人沮喪。

是否有其他人處理這個問題？有沒有人找到解決方案？

實例衝突，編碼器「一」增加whatever.txt和，編碼器「B」檢查增加了過濾器和新的.cpp文件和更新。獲取此：

<?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>

來源

2010-04-23 Crazy Eddie

我把這個技巧添加到http://stackoverflow.com/questions/2538149/global-ignore-pattern-for-tortoisesvn-visual-studio-2010 – 2010-04-23 17:31:55

我不會建議這樣做，直到問題如何共享沒有該文件的項目結構被回答。由於.filters文件丟失將整個事物變成一個扁平的結構，這實際上似乎是一個非常糟糕的主意。 – 2010-04-23 17:37:45

好的，我正在關注這個話題，看看答案是什麼。謝謝。 – 2010-04-23 18:47:45

他們是純XML文件，如Visual Studio的其他項目文件 - 我不明白爲什麼他們應該是任何更容易受到比其他項目文件的衝突。

這些文件是否被視爲二進制文件而不是文本？合併二進制文件將不起作用 - 檢查svn屬性以查看它們設置的MIME類型（如果沒有設置MIME類型，則應該沒問題）。如果設置了mime類型，則可能是您正在處理配置錯誤的automatic property。

最後，這是可能的人都在不斷地增加+刪除文件 - 如果是這樣，你可能只需要提交和更新更頻繁，直到項目落戶多一點。

你絕對不應該svn:ignore這些文件。

來源

2010-04-30 21:04:41

這個答案顯示了很多的承諾。事實上，汽車財產的東西沒有工作是不足爲奇的，因爲它看起來在這些事情的開頭有一些不是文字的時髦人物。儘管將文件的svn：mime-type設置爲「text/xml」並沒有解決問題。讓svn admin dude試圖找到系統範圍的方法，我們會嘗試。 – 2010-04-30 22:49:25

如果你可以通過http-common訪問你的svn，因爲許多人使用apache來託管svn - 你可以在你的webbrowser中下載過濾器文件並檢查（例如用螢火蟲或http fiddler）mime輸入文件的結果提供服務。 – 2010-05-01 19:03:02

文件開頭的「時髦字符」可以是一個Unicode字節順序標記（http://en.wikipedia.org/wiki/Byte_order_mark）嗎？鑑於Subversion區分文本文件和二進制文件的方式，對於UTF-8或UTF-16，BOM不應該是一個問題：http://subversion.apache.org/faq.html#binary-files。這會導致UTF-32出現問題，因爲其中兩個字節爲零。 – 2010-05-02 00:26:05

如果「.filters」文件是特定於用戶的配置的東西，那麼它很可能不屬於顛覆所有。您可以顛覆忽略使用svn的文件更改：忽略屬性：

 
svn propset svn:ignore '.filters' .

上面的命令將顛覆開始忽略更改名爲「.filters」的文件。

另一種選擇是強制Subversion來看待「.filters」文件作爲二進制文件：

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

上面的命令將導致「.filters」文件被當作一個二進制文件和將不被合併。

編輯
現在你已經解釋說，「.filters」文件是必不可少的項目，也是該問題可能是它被視爲二進制，而不是純文本，解決的辦法是該類型設置爲純文本：

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

來源

2010-04-30 00:47:15

這與其他人給出並刪除的答案相同。在項目中丟失過濾器會產生完全平坦的項目結構，以便所有文件都顯示在頂層。即使是小型項目也不適用。 – 2010-04-30 16:06:55

我會提供這對於.vcxproj.filters文件的用途：

當我創建與Visual Studio 2010中，版本10.0.40219一個C++項目。1 SP1Rel，它會產生一個在包括本文的項目文件夾命名ReadMe.txt文件：

<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).

所以，事實上，這證實了.vcxproj.filters文件支配了你在Solution Explorer中看到該文件夾結構。

來源

2013-04-12 13:20:53 DavidRR

我們遇到了同樣的問題。由於文本/二進制狀態，它們沒有被正確合併，而是因爲SVN合併的怪癖。

通常，如果一個人增加了一個新的文件到該項目，並承諾隨後差異將是這樣的：

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

同時，用戶2增加了一個新的文件，以相同的過濾器（即在文件夾節點解樹）：

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

當用戶2更新他們會遇到衝突

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

關鍵的是你如何解決衝突。如果您使用合併工具的'使用A然後B'選項，那麼您將以此結束：

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

這是無效的XML。不幸的是VisualStudio似乎並不總是抱怨這一點（儘管它通常會這樣做 - 似乎取決於改變的確切性質）。所以，你就可以結束了，從他們的過濾器孤立的一些文件 - 我認爲在這種情況下，它會嘗試完成第一<CLCompile>解決它：

<ClCompile Include="dir1\newfile1" />

這就意味着newfile1將出現在頂部該項目的級別而不是在dir1過濾器中。一旦出現了一些無效的節點，似乎你會開始得到更多的衝突，直到有人修復了該項目。

因此，解決所有這些問題的方法是，您需要讓用戶在解決衝突時瞭解文件的結構，而不是盲目地依賴合併工具。您必須確保每個條目都包含全部3行：開頭<CLCompile>或<CLInclude>，過濾器和結束標籤。

這整個問題只是真正存在，因爲xml的一個怪癖，衝突只會影響三條線中的一條或兩條。如果XML結束標記與過濾器位於同一行，則不會發生。

來源

2013-08-23 11:03:49

VS2010 .filter文件和SVN

回答

相關問題