Sollte ich der Quellcodeverwaltung .vcxproj.filter-Dateien hinzufügen?

169

Bei der Evaluierung von Visual Studio 2010 Beta 2 stelle ich fest, dass meine vcproj- Dateien im konvertierten Verzeichnis zu vcxproj- Dateien wurden. Neben jedem Projekt befinden sich auch vcxproj.filter- Dateien, die eine Beschreibung der Ordnerstruktur enthalten (\ Quelldateien, \ Header-Dateien usw.).

Denken Sie, dass diese Filterdateien pro Benutzer aufbewahrt werden sollten oder dass sie für die gesamte Entwicklergruppe freigegeben und in SCC eingecheckt werden sollten?

Mein derzeitiger Gedanke ist, sie einzuchecken, aber ich frage mich, ob es Gründe gibt, dies nicht zu tun, oder vielleicht gute Gründe, warum ich sie auf jeden Fall einchecken sollte.

Der offensichtliche Vorteil ist, dass die Ordnerstrukturen übereinstimmen, wenn ich mir den Computer eines anderen anschaue, aber vielleicht möchten sie die Dinge logisch neu organisieren?

— jschroedl
quelle

59

Frühere Versionen von Visual Studio (mindestens die Versionen 6.0 und 2008) speichern diese Informationen in ihrer eigenen Projektdatei (.dsp- bzw. .vcproj-Dateien), was natürlich gut zu SCC hinzugefügt werden kann.

Ich kann mir keinen Grund vorstellen, diese .filter-Dateien nicht in SCC aufzunehmen

— jrbjazz
quelle

Ich bin bei dir. Ich habe es eingecheckt. Danke!

— Jschroedl

111

Wir haben absichtlich den Filter gezogen. Dateiinformationen aus dem .vcproj, als wir in das .vcxproj MSBuild-Format übersetzt haben. Ein Grund ist genau das, worauf Sie hingewiesen haben, dass die Filter eine rein logische Ansicht sind und verschiedene Teammitglieder möglicherweise unterschiedliche Ansichten wünschen. Das andere ist, dass der Build manchmal so eingerichtet ist, dass er den Zeitstempel der Projektdatei überprüft und eine Neuerstellung auslöst, wenn sie sich geändert hat - da dies bedeuten kann, dass unterschiedliche Quelldateien erstellt werden müssen oder unterschiedliche Einstellungen usw. Ich nicht Denken Sie daran, ob wir tatsächlich mit dem Build ausgeliefert haben, der auf diese Weise ausgelöst wurde, aber die Idee war, dass wir keinen Neuaufbau auslösen wollten, nur weil sich die Filter geändert haben, da sie den Build nicht beeinflussen.

— Dan Moseley
quelle

3

Bei automatischen Neuerstellungen erstellen Sie, wenn sich eine Datei geändert hat (z. B. die Quelle). Jetzt hat sich nichts geändert, außer dass wir eine weitere Datei verwalten müssen.

— Gbjbaanb

3

Mit anderen Worten, Sie verwalten beide Dateien so, als wären sie eine. Ich glaube nicht, dass jemand anderes sie separat behandeln wird. Es ist eine nette Idee, aber ein bisschen Nachdenken über reale Praktiken hätte einen langen Weg zurückgelegt (wie das Einfügen der Laufzeit in WinSxS)

— gbjbaanb

9

Ich behandle sie separat. Für mich ist es umso besser, je weniger Mist im Rahmen des Projektstatus aufbewahrt werden muss. Ich denke, dies ist eine gute Entscheidung.

— Wallwall

6

Können wir diese Filter vollständig deaktivieren, wenn wir keinen abstrakten / logischen Baum verwenden möchten, sondern nur das einfache Dateisystem sehen möchten?

— Johan Boulé

4

@ JohanBoule: Ich stimme vollkommen zu! Sie sollten nur die Filter in der IDE verschrottet haben. Es gibt bereits eine logische Baumstruktur, die als "Dateisystem" bezeichnet wird. Derzeit gibt es viele Duplikate - jede Datei muss dem Dateisystem, dem Build-Skript (vcxproj), den Filtern (vcxproj.filters), der Quellcodeverwaltung und möglicherweise woanders hinzugefügt werden. Es verstößt gegen das DRY-Prinzip. Glücklicherweise scheinen die Filterdateien optional zu sein . Sie können sie einfach löschen und die Schaltfläche "Alle Dateien anzeigen" in der IDE verwenden. Schade, dass es nicht die Standardeinstellung ist.

— Yakov Galka

5

Ich habe gerade festgestellt, dass Sie mit Git .filter-Dateien markieren können, die als Vereinigung zum Zusammenführen behandelt werden sollen, um die Vereinfachung zu vereinfachen. Fügen Sie einfach die Zeile hinzu:

*.vcxproj.filters merge=union

zu Ihrer .gitattributes-Datei.

Weitere Informationen finden Sie unter Verwenden von .gitattributes zur Vermeidung von Zusammenführungskonflikten .

— Petersilie72
quelle

Der erwähnte Link sagt nicht, dass diese .filters-Datei "union" haben sollte, die in der gitattributes-Datei erwähnt wird.

— Ollydbg23

2

Aber es sagt, was merge=uniontut - nichts anderes wurde versprochen. Mit diesem Wissen und einer sehr umfassenden Vorstellung davon, wie * .filter-Dateien aussehen, ist es leicht zu erkennen, warum merge=unioneine gute Idee für diese Dateien ist.

— Peter Schneider

1

Es sollte nicht für den Fall hinzugefügt werden , die Sie verwenden CMake(oder ein Build - Tools) Dateien wie zu generieren *.sln, *.vcxproj, *.vcxproj.filtersusw., da diese Dateien vollständigen Pfad zu Ihrem Projektordner und andere enthalten können Ihren Computer nur bestimmte Ordner .

— V. Panchenko
quelle