Швидке запитання про TFS - Ви, хлопці, зареєстрували папки бін / налагодження в TFS? (якщо так, то чому?) Оскільки вміст цих папок динамічно генерується, чи краще залишити їх, щоб програміст не стикався з проблемами лише для читання?
Відповіді:
Як правило, управління джерелом найкраще використовувати лише для джерела, а згенеровані файли не є джерелом.
Є винятки. Іноді (використовуючи Visual Studio), можливо, ви захочете зберегти .pdb-файл для читання міні-відвалів. Іноді ви не можете дублювати ланцюжок інструментів, так що вам не обов'язково точно відтворити створені файли. У цих випадках ви в першу чергу зацікавлені в тому, щоб зробити це для випущеного програмного забезпечення, а не для кожної зміни VCS, і в будь-якому випадку вони можуть легко знаходитись у папках з версією. (Це, як правило, бінарні файли, так чи інакше, і не мають зрозумілих змін від однієї версії до іншої, і не дуже корисно від того, щоб бути у VCS.)
Проста відповідь? Ні. Не робіть цього! Я не можу придумати багато причин цього не робити, але немає причин, чому ви цього хотіли б.
Єдиний раз, коли я можу подумати, що ти перевіриш у dll, якщо це з бібліотеки третьої сторони, що ти не очікуєш, що кожен розробник має встановлений для створення. Але навіть досі це не знаходиться в папці бін.
Зважаючи на це, я працював в одній компанії, яка вимагала, щоб кожен пакет розгортання був поставлений під контроль джерела, але це було так, щоб ми могли відслідковувати різні складання, які ми надавали нашому клієнту, і легко могли відкотитись, якщо нам доведеться.
Ми не перевіряємо в папці bin в TFS. Як ви, напевно, помітили, якщо ви це зробите, кожен раз, коли будь-який розробник створює рішення, вони перевірять папку бін. Не добре. Однак є бібліотеки, які потрібні проекту для компіляції та запуску, і наше правило полягає в тому, що будь-який проект повинен бути відкритий з управління джерелами, і він повинен збиратись і запускатися. Отже, ми робимо те, щоб створити папку "BinRef" для будь-яких DLL-файлів, на які повинен посилатися проект, та створити посилання на проект для копії в папці BinRef. Папка BinRef це перевіряється на TFS.
Інша перевага цього підходу полягає в тому, що BinRef завжди знаходиться на кореневому рівні веб-проекту. Якщо мій проект живе C:\Projects\Marcie\SomeProjectCategory\ProjectAі я створюю посилання на DLL, який сидить C:\DLLsThatILike, посилання буде виглядати щось на зразок
\..\..\..\NiceThing.dll
. Ви можете зберігати файли свого проекту, а C:\ProjectAце означає, що посилання на проект NiceThing відображатиметься на вашій машині. Сподіваємось, люди так не роблять посилань, але я бачив, що це відбувається.
Ми перевіряємо вміст бінних каталогів як частина нашого процесу запиту на зміни. Щоб уникнути проблем лише для читання, ми копіюємо вміст в окрему папку і перевіряємо їх звідти. Наша корпоративна політика вимагає, щоб усі бінарні файли, які йдуть на виробництво, були зареєстровані окремо від джерела. Це не найкраще рішення, але воно працює, і воно дає нам точні файли, які знаходяться у виробництві.
Я не вагаюся перевірити будь-який нетекстовий файл у контролі джерела. Особливо ті, які повинні бути створені розробником. Мені також подобається зберігати інші бінарні файли, такі як зображення та PDF-файли, зберігати в інших місцях для кожного тегу / випуску.
Ні, але наш внутрішній інструмент управління проектами справляється автоматично, що дратує чорт у мене.
Моє рішення полягає в тому, щоб позначити всі файли при випуску та налагодженні як записи, і коли TFS скаржиться, я кажу, що він ігнорує файли, тому у мене ніколи не виникає проблем зі збоєм збірки.
Я зберігаю деякі згенеровані двійкові файли, наприклад .NET interops з іншого проекту. Отже, якщо у мене є проект A, який створює об'єкт COM, а потім ви використовуєте цей об'єкт COM у дуже слабко пов'язаному проекті B, який використовує його через .NET interop, я перевіряю, що інтероп, що генерується з проекту A, в проект B. Це це не дуже гарна ідея, але вона має кудись піти, оскільки AFAIK Visual Studio не створить інтероп для Вашого автоматично під час збирання.
На мою думку, не зберігання двійкових файлів у контролі джерел - одна з найпоширеніших помилок. Їх слід зберігати, упорядковувати, базувати / маркувати разом із джерелами, а також створювати інструменти. Налаштуйте себе, будуючи програмне забезпечення, яке не відстежується ...