Dlaczego nie powinienem sprawdzać folderów bin i obj, w SVN

Question

To wydaje się być bardzo podstawowe pytanie, ale chcę poznać odpowiedź. Używam Subversion (SVN) do kontroli kodu źródłowego i sprawdzałem wszystkie pliki, ale klient poprosił mnie o utworzenie reguły w SVN, aby uniknąć sprawdzania w folderach bin i.
Dlaczego nie powinienem sprawdzać folderów bin i i i i ?

klient poprosił mnie również, aby zachować plik rozwiązania poza folderu repozytorium. Dlaczego?

Answer 1

Nie powinieneś dodawać żadnych plików tymczasowych do SVN, są tymczasowe. Cały katalog obj składa się z plików, które są tworzone podczas procesu budowania, a następnie są odrzucane. (Oczywiście, pozostają na dysku, ponieważ niektóre są ponownie używane, tak jak pamięć podręczna, gdy pliki źródłowe się nie zmieniają, ale to jest jedyny powód, dla którego nie są usuwane po każdym kompilacji).

Katalog bin to nieco inna sprawa. Można dodawać pliki binarne do SVN, prawdopodobnie już to robisz dla ikon i plików graficznych. Niektóre osoby dodają również zbudowane pliki binarne, to decyzja, która zależy od procesów zarządzania konfiguracją, nie ma "złej" odpowiedzi. Czasami jednak katalog bin może zostać wypełniony innymi plikami, których nie chcesz dodawać. Jeśli budujesz aplikacje .net, dostaniesz ładunek zależnych bibliotek dll skopiowany do katalogu bin, który nie jest ściśle częścią twojego projektu. Dodanie ich spowoduje po prostu powiększenie twojego repozytorium bez żadnych korzyści. Podobnie są obsługiwane pliki binarne w bin, takie jak pliki symboli debugowania .pdb. Te też nie są naprawdę potrzebne.

Dla pliku rozwiązania, nie jestem pewien pytanie, ale jeśli nie można go sprawdzić, to dlatego, że plik .sln jest po prostu "wrapper" dla jednego lub więcej plików projektu. Nie jest to bezwzględnie potrzebne do zbudowania projektu studia wizualnego, ponieważ nowy projekt zostanie utworzony w razie potrzeby. Domyślam się, że Twoi użytkownicy mogą tworzyć własne pliki .sln z różnymi grupami projektów, dzięki czemu każdy z nich będzie inny dla każdego użytkownika. To byłby powód, aby zapobiec checkin, więc każdy użytkownik nie nadpisałby swoich własnych plików (chociaż istnieją sposoby, aby użytkownik mógł zapobiec modyfikacji pliku przechowywanego w svn).

Wygląda na to, że twoja strategia konfiguracji nie wymaga dodawania żadnych plików binarnych do svn. W takim przypadku jest to bardzo dobry pomysł, aby temu zapobiec przypadkowo z hakiem przed popełnieniem błędu. Zaleciłabym także dodanie tych wyjątków do ignorowanych globalnych po stronie klienta, aby pomóc użytkownikom w próbach dodawania tych plików w pierwszej kolejności.

Answer 2

"nie powinien" nie dotyczy wszystkich. Ale ogólnie:

1) Nie sprawdzam pliki binarne, które mogą być generowane z kodem.

2) SVN to system wersjonowania kodu źródłowego, a nie zaprojektowane z myślą plików binarnych. Tak, SVN i inne VCS mogą obsługiwać pliki binarne, ale nie jest to ich przeznaczeniem, zwłaszcza po punkcie 1)

3) Ponieważ są one generowane przez kod źródłowy, będą się często zmieniać i nie przypominają bibliotek, które rzadko się zmieniają. Często zmieniające się binaria opodatkowują VCS, ponieważ jakikolwiek VCS nie może prawidłowo obsługiwać plików binarnych i zwykle przechowujesz więcej przy każdej zmianie w plikach binarnych, ponieważ różnicowanie (delta) nie jest tak wydajne jak w przypadku kodu źródłowego.

Jadąc do roztworu (.sln) plików, jest idealnym miejscem do sprawdzał je do repozytorium, choć nie jest to absolutnie konieczne. Ale większość, jeśli nie wszystkie, projektu .Net są oparte na Visual Studio, a nawet do celów kompilacji, posiadanie pliku .sln znacznie ułatwia pracę, ponieważ możesz wywołać msbuild na pliku sln zamiast plików csproj (lub innych projektów). Dostajesz inne korzyści, takie jak właściwa kompilacja zależności, kompilacja równoległa itp.

Answer 3

Nie powinieneś naprawdę sprawdzać żadnych plików użytkownika ani wygenerowanych plików wyjściowych, ponieważ za każdym razem, gdy będziesz sprawdzać, będziesz ponownie rekompilował zmiany w wynikach. Polecam zignorować bin, obj i .suo (nie .sln) jako punkt wyjścia, ponieważ zostaną one odtworzone za pomocą kompilacji, a następnie zignorują wszystkie inne, które są specyficzne dla użytkownika lub regenerowane przy każdej kompilacji.