Czy meldujesz się w folderze bin lub debugowaniu (i dllach) w swoim TFS?

Szybkie pytanie o TFS - czy wy rejestrujecie foldery bin / debugowania w TFS? (jeśli tak, to dlaczego?) Ponieważ zawartość tych folderów jest generowana dynamicznie, czy lepiej je pominąć, aby programista nie napotkał problemów tylko do odczytu?

Zasadniczo kontrola źródła najlepiej jest stosować tylko do źródła, a generowane pliki nie są źródłowe.

Istnieją wyjątki. Czasami (używając Visual Studio) możesz chcieć zachować plik .pdb do odczytu minidumps. Czasami nie można powielić łańcucha narzędzi, dzięki czemu nie można dokładnie odtworzyć wygenerowanych plików. W takich przypadkach jesteś przede wszystkim zainteresowany zrobieniem tego dla wydanego oprogramowania, a nie dla każdej zmiany VCS, a w każdym razie mogą one łatwo znajdować się w wersjonowanych folderach. (W każdym razie są to zazwyczaj pliki binarne i nie zawierają zrozumiałych zmian między wersjami i nie korzystają tak bardzo z bycia w VCS.)

Prosta odpowiedź? Nie. Nie rób tego! Nie mogę wymyślić wielu powodów, aby tego nie robić, ale nie ma powodu, dla którego miałbyś chcieć.

Jedyny moment, w którym mogę pomyśleć, że sprawdziłbyś bibliotekę DLL, to jeśli pochodzi ona z biblioteki innej firmy, której nie spodziewasz się, że każdy programista zainstalował ją. Ale nawet to nie znajduje się w folderze bin.

Biorąc to pod uwagę, pracowałem w jednej firmie, która wymagała, aby każdy pakiet wdrożeniowy był poddany kontroli źródła, ale było to tak, że mogliśmy śledzić różne kompilacje, które daliśmy naszemu klientowi i łatwo moglibyśmy wycofać, gdybyśmy musieli.

Nie wpisujemy folderu bin do TFS. Jak zapewne zauważyłeś, jeśli to zrobisz, za każdym razem, gdy jakiś programista skompiluje rozwiązanie, będzie sprawdzał folder bin. Niedobrze. Istnieją jednak biblioteki, których projekt potrzebuje do skompilowania i uruchomienia, a naszą zasadą jest, że każdy projekt powinien mieć możliwość otwarcia z poziomu kontroli źródła, a także powinien zostać skompilowany i uruchomiony. Dlatego tworzymy folder „BinRef” dla wszystkich bibliotek DLL, do których projekt musi się odwoływać, i tworzymy odwołania projektu do kopii w folderze BinRef. Folder BinRef jest rejestrowany w TFS.

Inną zaletą tego podejścia jest to, że BinRef jest zawsze na poziomie głównym projektu internetowego. Jeśli mój projekt będzie trwał C:\Projects\Marcie\SomeProjectCategory\ProjectAi utworzę odwołanie do biblioteki DLL, która się w nim znajduje C:\DLLsThatILike, odniesienie to będzie wyglądać podobnie

\..\..\..\NiceThing.dll

. Możesz przechowywać pliki projektu, C:\ProjectAco oznacza, że ​​odwołanie do projektu NiceThing zostanie wysadzone na twoim komputerze. Mam nadzieję, że ludzie nie robią referencji w ten sposób, ale widziałem, jak to się dzieje.

Sprawdzamy zawartość katalogów bin w ramach procesu żądania zmiany. Aby uniknąć problemów tylko do odczytu, kopiujemy zawartość do osobnego folderu i stamtąd. Nasza polityka korporacyjna wymaga, aby wszystkie pliki binarne, które trafiają do produkcji, były rejestrowane oddzielnie od źródła. To nie jest najlepsze rozwiązanie, ale działa i daje nam dokładne pliki, które są w produkcji.

Waham się, aby sprawdzić dowolny plik nietekstowy w celu kontroli źródła. Zwłaszcza te, które powinien wygenerować programista. Lubię również przechowywać inne pliki binarne, takie jak obrazy i pliki PDF, spakowane i przechowywane w innym miejscu dla każdego tagu / wydania.

Nie, ale nasze wewnętrzne narzędzie kontroli projektu działa automatycznie, co mnie denerwuje.

Moim rozwiązaniem jest oznaczenie wszystkich plików w wersji i debugowaniu jako zapisywalnych, a gdy TFS narzeka, mówię, aby zignorować pliki, więc nigdy nie mam problemu z niepowodzeniem kompilacji.

Unikam wprowadzania ich w kontrolę źródła. Są to informacje nadmiarowe, pliki binarne mogą być budowane przez kod źródłowy w tej wersji. Ponadto kod źródłowy jest zawsze aktualny, kompilacje mogą nie być w trakcie zatwierdzania.

Zapisuję niektóre wygenerowane pliki binarne, takie jak interakcje platformy .NET z innego projektu. Więc jeśli mam projekt A, który tworzy obiekt COM, a następnie użyjesz tego obiektu COM w bardzo luźno powiązanym projekcie B, który używa go za pośrednictwem interfejsu .NET, sprawdzam interop wygenerowany z projektu A do projektu B. nie jest to dobry pomysł, ale musi gdzieś pójść, ponieważ AFAIK Visual Studio nie utworzy interopu automatycznie podczas kompilacji.

Moim zdaniem brak przechowywania plików binarnych w kontroli źródła jest jednym z najczęstszych błędów. Powinny być przechowywane, wersjonowane, bazowane / oznaczone wraz ze źródłami, a także narzędziami do budowania. Przygotuj się na budowę niewykrywalnego oprogramowania ...