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

135

Während der Evaluierung von Visual Studio 2010 Beta 2 sehe ich, dass im konvertierten Verzeichnis meine vcproj Dateien vcxproj Dateien wurden. Es gibt auch vcxproj.filter Dateien neben jedem Projekt, die eine Beschreibung der Ordnerstruktur (\ Quelldateien, \ Header Files, etc.) zu enthalten scheinen.Sollte ich .vcxproj.filter-Dateien zur Quellcodeverwaltung hinzufügen?

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

Meine heutige Denken ist ihnen zu lesen, aber ich frage mich, ob es irgendwelche Gründe dafür sind nicht das zu tun, oder vielleicht gute Gründe, warum ich auf jeden Fall überprüfen sollten sie in.

Der offensichtliche Vorteil ist, dass die Ordnerstrukturen wird passen, wenn ich auf die Maschine eines anderen schaue, aber vielleicht möchten sie die Dinge logisch reorganisieren?

Quelle

2009-12-01 jschroedl

Frühere Versionen von Visual Studio (mindestens 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 nicht aus irgendeinem Grund denken kann, nicht um diesen .filter Dateien in SCC

Quelle

2009-12-02 17:02:31 jrbjazz

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

Wir zogen absichtlich die .filter. Dateiinformationen aus dem .vcproj, wenn wir in das .vcxproj MSBuild-Format übersetzten. Ein Grund ist genau, was Sie darauf hingewiesen haben, dass die Filter nur eine logische Ansicht sind und verschiedene Teammitglieder unterschiedliche Ansichten wünschen. Der 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 - weil das bedeuten kann, dass verschiedene Quelldateien oder andere Einstellungen erstellt werden müssen. Ich erinnere mich, wenn wir tatsächlich mit dem Build-Triggering auf diese Weise ausgeliefert wurden, aber die Idee war, dass wir keine Wiederherstellung auslösen wollten, nur weil sich die Filter geändert haben, da sie den Build nicht beeinflussen.

Quelle

2010-05-15 22:29:31

für automatische Umbauten, Sie bauen, wenn * any * Datei geändert hat (zB Quelle), so hat sich jetzt nichts geändert, außer wir haben noch eine andere Datei zu verwalten. – gbjbaanb

Am Ende haben wir sie eingecheckt und waren mit diesem Arrangement bisher zufrieden. Es stellt sich heraus, dass es für uns angenehmer ist, mit anderen Entwicklern zu arbeiten, wenn sie dieselbe Filterstruktur haben. – jschroedl

Mit anderen Worten, Sie verwalten beide Dateien als wären sie eins. Ich glaube nicht, dass jemand anderes sie getrennt behandeln wird. Es ist eine nette Idee, aber ein paar Gedanken über reale Praktiken hätten einen langen Weg zurückgelegt (wie die Laufzeit in WinSxS) – gbjbaanb

Ich habe gerade festgestellt, dass Sie, wenn Sie Git verwenden, markieren können. Filter Dateien als eine Union zum Zusammenführen behandelt werden, um es einfacher zu machen. Fügen Sie einfach die Zeile:

*.vcxproj.filters merge=union

zu Ihrer .gitattributes-Datei hinzu.

Weitere Informationen finden Sie unter Using .gitattributes to avoid merge conflicts.

Quelle

2017-01-10 01:20:27 parsley72

Der erwähnte Link sagt nicht, dass diese .filters-Datei "union" in der gitattributes-Datei enthalten sollte. – ollydbg23

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

Antwort

Verwandte Themen