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

100

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!

jlembke
źródło
21
Uważam, że jest to plik .SUO, którego NIE chcesz zatwierdzać.
apandit
Tak dla porządku, uważam, że listy zadań (jeśli ich używasz) są przechowywane w pliku .SUO ... Więc chociaż możesz nie chcieć przypisywać ich do kontroli źródła, możesz nie chcieć ich „po prostu usunąć” jako obca skorupa.
Benjol

Odpowiedzi:

68

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
Trevor Robinson
źródło
2
Mam również regułę ignorowania wyników testów jednostkowych. Niektórzy mogą je sprawdzać, ale nie lubię bałaganu
Matthew Whited
9
+1 - Osobiście też nie popełniam niczego, co zostanie zbudowane, więc bin / i obj /
Steven Evers
Zatwierdzam tylko pliki .sln, które zawierają więcej niż 1 projekt
Justin,
2
oto moja subversion Global ignore patter: * .vsmdi * .suo * / [Bb] in [Bb] in * / obj obj TestResults *. [Uu] ser * Thumbs.db * Web.Publish.xml * WebApplication.Publish. xml * Web.log
Merritt
Oto często udostępniany plik .gitignore, który zawiera pliki tymczasowe, wyniki kompilacji i pliki generowane przez popularne dodatki programu Visual Studio.
Lauren Van Sloun
58

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

Lou Franco
źródło
3
Zdecydowanie .sln zawiera odniesienia do plików .prj (projektów)
dplante
20

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.

JaredPar
źródło
13

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.

Mehrdad Afshari
źródło
8

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.

Brian Rasmussen
źródło
Wygląda na to, że to może być odpowiedź na jedno z moich długich pytań bez odpowiedzi ( stackoverflow.com/questions/1490728/… ), czy jest jakaś szansa na zdobycie kopii tej wtyczki?
Benjol
@Benjol: Przepraszamy, nie, to jest wewnętrzne narzędzie. Oprócz funkcji opisanych powyżej integruje się również z wieloma innymi systemami wewnętrznymi, więc jest bardzo specyficzny dla sposobu, w jaki działamy. Jeśli potrzebujesz tylko części rozwiązania / projektu, nie jest to trudne do wdrożenia.
Brian Rasmussen
OK, tylko jedno, czy w swoim „dużym rozwiązaniu” masz odniesienia do projektów lub pliki? A jeśli programista doda nowe odniesienie do pliku / projektu, czy wtyczka wykonuje odpowiednią konwersję z powrotem przed zalogowaniem się? Jak radzisz sobie z zależnościami, których deweloper nie zdecydował się wyewidencjonować?
Benjol
8

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 .

Groo
źródło
1
Nie zgadzam się z określeniem „dowolny plik generowany automatycznie”.
Mehrdad Afshari
@Mehrdad Czy uważasz, że pliki Intelisense również powinny zostać zatwierdzone?
Edison Gustavo Muenz
1
@Edison: Nie. Mam na myśli na przykład automatycznie generowane pliki źródłowe, takie jak kontekst danych LINQ to SQL.
Mehrdad Afshari
2
Czy pliki Formname.Designer.cs nie są uważane za wygenerowane automatycznie?
jasonh
1
Miałem na myśli pliki generowane podczas kompilacji. Często to widzę - ktoś zatwierdza plik, który jest budowany automatycznie, a następnie SVN zgłasza zmianę tylko dlatego, że zmieniono jakiś komentarz.
Groo
5

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

Arnkrishn
źródło
4

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

Josh Weatherly
źródło
4

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.

Ferruccio
źródło
2

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.

kemiller2002
źródło
2

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

Burmistrz Niesamowite
źródło
1

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.

Joe
źródło
1

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

Michael
źródło
1

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.

Sylvain Rodrigue
źródło
0

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

Kod Silverback
źródło
1
To zabawne ... SLN były jedynymi plikami, które kiedykolwiek musiałem naprawić ... ale problemy były spowodowane tym, że deweloperzy nie byli ostrożni podczas łączenia.
Matthew Whited