Czy domena .sln powinna podlegać kontroli źródła?

Czy jest najlepszą praktyką zatwierdzanie pliku .sln do kontroli źródła? Kiedy jest to właściwe lub niewłaściwe?

Aktualizacja W odpowiedziach znalazło się kilka dobrych punktów. Dzięki za odpowiedzi!

Myślę, że z innych odpowiedzi jasno wynika, że ​​pliki rozwiązań są przydatne i powinny zostać zatwierdzone, nawet jeśli nie są używane w oficjalnych kompilacjach. Są przydatne dla każdego, kto korzysta z funkcji programu Visual Studio, takich jak Przejdź do definicji / deklaracji.

Domyślnie nie zawierają ścieżek bezwzględnych ani żadnych innych artefaktów specyficznych dla komputera. (Niestety, niektóre narzędzia dodatków nie obsługują prawidłowo tej właściwości, na przykład AMD CodeAnalyst). Jeśli uważnie używasz ścieżek względnych w plikach projektu (zarówno C ++, jak i C #), będą one niezależne od komputera też.

Prawdopodobnie bardziej przydatnym pytaniem jest: jakie pliki należy wykluczyć? Oto zawartość mojego pliku .gitignore dla moich projektów VS 2008:

*.suo
*.user
*.ncb
Debug/
Release/
CodeAnalyst/

(Ostatni wpis dotyczy tylko programu profilującego AMD CodeAnalyst).

W przypadku VS 2010 należy również wykluczyć następujące elementy:

ipch/
*.sdf
*.opensdf

Tak - myślę, że to zawsze jest właściwe. Ustawienia użytkownika znajdują się w innych plikach.

Tak, powinieneś to zrobić. Plik rozwiązania zawiera tylko informacje o ogólnej strukturze rozwiązania. Informacje dotyczą rozwiązania globalnego i prawdopodobnie są wspólne dla wszystkich programistów w Twoim projekcie.

Nie zawiera żadnych ustawień użytkownika.

Zdecydowanie powinieneś to mieć. Oprócz powodów, o których wspominali inni ludzie, konieczne jest, aby możliwe było jednoetapowe tworzenie całych projektów.

Generalnie zgadzam się, że pliki rozwiązań powinny być rejestrowane, jednak w firmie, w której pracuję, zrobiliśmy coś innego. Mamy dość duże repozytorium, a programiści od czasu do czasu pracują nad różnymi częściami systemu. Aby wesprzeć nasz sposób pracy, musielibyśmy mieć jeden duży plik rozwiązania lub kilka mniejszych. Oba mają kilka niedociągnięć i wymagają ręcznej pracy ze strony programistów. Aby tego uniknąć, stworzyliśmy wtyczkę, która to wszystko obsługuje.

Wtyczka umożliwia każdemu deweloperowi pobranie podzbioru drzewa źródłowego do pracy, po prostu wybierając odpowiednie projekty z repozytorium. Wtyczka następnie generuje plik rozwiązania i modyfikuje pliki projektu w locie dla danego rozwiązania. Obsługuje również odniesienia. Innymi słowy, deweloper musi tylko wybrać odpowiednie projekty, a następnie wygenerować / zmodyfikować niezbędne pliki. Pozwala nam to również dostosować różne inne ustawienia, aby zapewnić standardy firmy.

Ponadto używamy wtyczki do obsługi różnych zasad ewidencjonowania, co generalnie zapobiega przesyłaniu przez użytkowników błędnego / niezgodnego kodu do repozytorium.

Tak, powinieneś zobowiązać się do:

• rozwiązanie (* .sln),
• pliki projektu,
• wszystkie pliki źródłowe,
• pliki konfiguracyjne aplikacji
• budować skrypty

Rzeczy, które powinny nie dopuszczają to:

• pliki opcji użytkownika rozwiązania (.suo),
• buduj wygenerowane pliki (np. używając skryptu kompilacji) [Edytuj:] - tylko jeśli wszystkie niezbędne skrypty i narzędzia do budowania są dostępne pod kontrolą wersji (aby upewnić się, że kompilacje są autentyczne w historii cvs)

Jeśli chodzi o inne automatycznie generowane pliki, istnieje osobny wątek .

Tak, powinien być częścią kontroli źródła. Kiedykolwiek dodasz / usuniesz projekty z aplikacji, .sln zostanie zaktualizowany i dobrze byłoby mieć go pod kontrolą źródła. Umożliwiłoby to pobranie 2 wersji kodu aplikacji z powrotem i bezpośrednie wykonanie kompilacji (jeśli w ogóle jest to wymagane).

Tak, zawsze chcesz dołączyć plik .sln, zawiera on łącza do wszystkich projektów znajdujących się w rozwiązaniu.

W większości przypadków dobrym pomysłem jest przesłanie plików .sln do kontroli źródła.

Jeśli twoje pliki .sln są generowane przez inne narzędzie (takie jak CMake), prawdopodobnie niewłaściwe jest umieszczanie ich w kontroli źródła.

Robimy, ponieważ wszystko jest zsynchronizowane. Wszystkie niezbędne projekty znajdują się razem i nikt nie musi się martwić o brak jednego. Nasz serwer kompilacji (Ant Hill Pro) również używa sln do określenia, które projekty zbudować dla wydania.

Zazwyczaj wszystkie nasze pliki rozwiązań umieszczamy w katalogu rozwiązań. W ten sposób trochę oddzielamy rozwiązanie od kodu i łatwiej jest wybrać projekt, nad którym muszę popracować.

Jedynym przypadkiem, w którym mógłbyś nawet rozważyć, aby nie przechowywać go w kontroli źródła, byłby, gdybyś miał duże rozwiązanie z wieloma projektami, które było w kontroli źródła, i chciałbyś utworzyć małe rozwiązanie z niektórymi projektami z głównego rozwiązania dla niektórych prywatny wymóg przejściowy.

Tak - wszystko, co służy do generowania produktu, powinno podlegać kontroli źródła.

Przechowujemy lub rozwiązujemy pliki w kontroli wersji TFS. Ale ponieważ główne rozwiązanie jest naprawdę duże, większość programistów ma osobiste rozwiązanie zawierające tylko to, czego potrzebują. Główny plik rozwiązania jest najczęściej używany przez serwer kompilacji.

.slns to jedyna rzecz, z którą nie mieliśmy problemów w tfs!