Czy powinienem dodać pliki .vcxproj.filter do kontroli źródła?

169

Oceniając Visual Studio 2010 Beta 2, widzę, że w katalogu przebudowanej, moi vcproj pliki stał vcxproj plików. Obok każdego projektu znajdują się również pliki vcxproj.filter, które wydają się zawierać opis struktury folderów (\ Source Files, \ Header Files itp.).

Czy uważasz, że te pliki filtrów powinny być przechowywane dla poszczególnych użytkowników, czy też powinny być udostępniane całej grupie deweloperów i wpisywane do SCC?

Obecnie myślę o sprawdzeniu ich, ale zastanawiam się, czy są jakieś powody, aby tego nie robić, albo może dobre powody, dla których powinienem zdecydowanie je zameldować.

Oczywistą korzyścią jest to, że struktury folderów będą się zgadzać, jeśli patrzę na komputer innej osoby, ale może chcieliby logicznie uporządkować rzeczy?

— jschroedl
źródło

59

Poprzednie wersje programu Visual Studio (przynajmniej wersje 6.0 i 2008) przechowują te informacje we własnym pliku projektu (odpowiednio pliki .dsp i .vcproj), który oczywiście dobrze jest dodać do SCC.

Nie przychodzi mi do głowy żaden powód, aby nie umieszczać tych plików .filter w SCC

— jrbjazz
źródło

Jestem z tobą. Sprawdziłem to. Dzięki!

— jschroedl

111

Celowo wyciągnęliśmy .filter. informacje o plikach z .vcproj po przetłumaczeniu na format .vcxproj MSBuild. Jednym z powodów jest dokładnie to, co wskazałeś, że filtry są czysto logicznym widokiem, a różni członkowie zespołu mogą chcieć różnych poglądów. Po drugie, czasami kompilacja jest skonfigurowana do sprawdzania sygnatury czasowej pliku projektu i wyzwalania odbudowy, jeśli uległa zmianie - ponieważ może to oznaczać, że są różne pliki źródłowe do zbudowania lub inne ustawienia itp. Nie. Przypomnijmy sobie, że faktycznie wysyłaliśmy z wyzwalaniem kompilacji w ten sposób, ale chodziło o to, że nie chcieliśmy wywoływać przebudowy tylko dlatego, że zmieniły się filtry, ponieważ nie mają one wpływu na kompilację.

— dan moseley
źródło

3

w przypadku automatycznej przebudowy budujesz, jeśli jakikolwiek plik się zmienił (np. źródło), więc teraz nic się nie zmieniło, poza tym, że mamy kolejny plik do zarządzania.

— gbjbaanb

3

innymi słowy, zarządzasz obydwoma plikami tak, jakby były jednym. Nie sądzę, żeby ktokolwiek inny traktował ich osobno. To fajny pomysł, ale trochę przemyślenia na temat praktyk w świecie rzeczywistym przeszłoby długą drogę (jak umieszczenie środowiska wykonawczego w WinSxS)

— gbjbaanb

9

Traktuję je osobno. Jeśli o mnie chodzi, im mniej bzdur trzeba zachować w ramach stanu projektu, tym lepiej, więc myślę, że to dobra decyzja.

— rwallace

6

Czy możemy całkowicie wyłączyć te filtry, jeśli nie chcemy używać żadnego abstrakcyjnego / logicznego drzewa, ale tylko zobaczyć zwykłe drzewo systemu plików?

— Johan Boulé

4

@JohanBoule: Całkowicie się zgadzam! Powinni byli po prostu wyrzucić filtry w IDE. Istnieje już logiczna struktura drzewa i nazywa się to „systemem plików”. Obecnie jest dużo duplikatów - każdy plik musi zostać dodany do systemu plików, do skryptu budującego (vcxproj), filtrów (vcxproj.filters), kontroli źródła i być może gdzie indziej. To narusza zasadę SUCHY. Na szczęście wydaje się, że pliki filtrów są opcjonalne . Możesz je po prostu usunąć i użyć przycisku „Pokaż wszystkie pliki” w IDE. Szkoda, że nie jest to domyślne.

— Yakov Galka

5

Właśnie odkryłem, że jeśli używasz Gita, możesz oznaczyć pliki .filter, aby były traktowane jako unia do scalania, aby było to prostsze. Po prostu dodaj linię:

*.vcxproj.filters merge=union

do pliku .gitattributes.

Aby uzyskać więcej informacji, zobacz Używanie .gitattributes w celu uniknięcia konfliktów przy scalaniu .

— pietruszka72
źródło

Wspomniany odnośnik nie mówi, że ten plik .filters powinien mieć "union" wymieniony w pliku gitattributes.

— ollydbg

2

Ale mówi, co merge=unionrobi - nic więcej nie zostało obiecane. Mając tę wiedzę i bardzo ogólne pojęcie o tym, jak wyglądają pliki * .filter, łatwo jest zrozumieć, dlaczego merge=unionjest to dobry pomysł na te pliki.

— Peter Schneider

1

To nie powinno być dodawane w przypadku używanego CMake(lub podobne narzędzia kompilacji) do generowania plików, takich jak *.sln, *.vcxproj, *.vcxproj.filtersitd., Ponieważ te pliki mogą zawierać pełną ścieżkę do folderu projektu i innych tylko konkretnych folderów komputera .

— V. Panczenko
źródło