Вы проверяете папки bin или debug (и dll) в своем TFS?

11

Быстрый вопрос о TFS - Ребята, вы регистрируете папки bin / debug в TFS? (если так, почему?) Поскольку содержимое этих папок генерируется динамически, лучше не указывать их, чтобы у программиста не возникало проблем, связанных только с чтением?

aggietech
источник
Возможно, вас заинтересует это предложение по обмену стека . Он почти готов начать бета, просто нужно еще немного.
великий волк

Ответы:

27

Как правило, управление исходным кодом лучше всего использовать только для источника, а сгенерированные файлы не являются источником.

Есть исключения. Иногда (используя Visual Studio) вы можете захотеть сохранить файл .pdb для чтения мини-дампов. Иногда вы не можете продублировать цепочку инструментов, чтобы вы не могли точно воссоздать сгенерированные файлы. В этих случаях вы в первую очередь заинтересованы делать это для выпущенного программного обеспечения, а не для каждого изменения VCS, и в любом случае они могут легко находиться в версионных папках. (Во всяком случае, это, как правило, двоичные файлы, и они не имеют понятных изменений от одной версии к другой, и не очень-то выигрывают от того, что находятся в VCS.)

Дэвид Торнли
источник
6
Если вы заинтересованы в сохранении отладочных символов, вам лучше настроить сервер символов . Если вы все сделаете правильно (с индексацией исходного кода), отладка мини-дамп сначала извлечет символы с вашего сервера символов, а затем соответствующий источник из вашего управления исходным кодом ... Если вы просто отметите и пометите каждую сборку, вам придется сделать это вручную.
Shog9
8

Простой ответ? Нет, не делай этого! Я не могу придумать много причин, чтобы этого не делать, но нет причин, по которым вы бы этого хотели.

Единственный раз, когда я могу подумать, что вы проверяете dll, это если вы работаете со сторонней библиотекой, которую, по вашему мнению, не должен устанавливать каждый разработчик. Но даже в этом случае, это не находится в папке мусорного ведра.

Тем не менее, я работал в одной компании, которая требовала, чтобы каждый пакет развертывания был помещен в систему контроля версий, но это было так, что мы могли отслеживать различные сборки, которые мы давали нашему клиенту, и могли легко откатываться, если бы это было необходимо.

Tyanna
источник
1
Основная причина не делать этого: Сколько терабайт хранилища вы хотите использовать для управления исходным кодом?
EKW
1
Например, @EKW C # исторически не создает одинаковые двоичные файлы из одного источника. Теперь это может отличаться от .NET Core, но это было одной из причин, чтобы сохранить сгенерированные двоичные файлы для выпущенных сборок, например. Я бы не стал их контролировать. Это не правильный инструмент для этой работы.
Шив
5

Мы не проверяем в папке bin в TFS. Как вы, наверное, заметили, если вы сделаете это, каждый раз, когда любой разработчик создает решение, он будет проверять папку bin. Нехорошо. Однако существуют библиотеки, которые необходимы проекту для компиляции и запуска, и наше правило состоит в том, что любой проект должен открываться из системы контроля версий, а также должен компилироваться и запускаться. Поэтому мы создаем папку «BinRef» для любых библиотек DLL, на которые должен ссылаться проект, и создаем ссылки проекта на копию в папке BinRef. Папка BinRef это проверяется на TFS.

Другое преимущество этого подхода заключается в том, что BinRef всегда находится на корневом уровне веб-проекта. Если мой проект живет, C:\Projects\Marcie\SomeProjectCategory\ProjectAи я создаю ссылку на библиотеку DLL, которая находится внутри C:\DLLsThatILike, ссылка в конечном итоге будет выглядеть примерно так:

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

, Вы можете хранить файлы своего проекта, C:\ProjectAчто означает, что ссылка на проект NiceThing будет взорвана на вашем компьютере. Надеюсь, люди не делают ссылки таким образом, но я видел, как это произошло.

Марси
источник
2

Мы регистрируем содержимое каталогов bin как часть нашего процесса запроса на изменение. Чтобы избежать проблем только для чтения, мы копируем содержимое в отдельную папку и регистрируем их оттуда. Наша корпоративная политика требует, чтобы все двоичные файлы, отправляемые в производство, регистрировались отдельно от исходного кода. Это не лучшее решение, но оно работает, и оно дает нам точные файлы, которые находятся в производстве.

Вальтер
источник
2
Сначала я собирался пройти мимо этого ответа, потом подумал об этом немного больше. В моей компании у нас на самом деле нет плана по восстановлению после стихийного бедствия (слишком долго, чтобы о нем говорить). Это может быть полезно в случае необходимости начинать с нуля. Я мог бы просто вытащить двоичные файлы из системы контроля версий, выбросить их на сервер и все готово.
user7676
@ user7676 - вы можете просто перекомпилировать код по номеру версии, которая находится в производстве. Но, конечно же, если у вас нет плана аварийного восстановления и вы находитесь в какой-то степени, вам будет проще и быстрее. PS. ВАМ НУЖЕН ПЛАН DR!
Али
1

Я не решаюсь проверить любой нетекстовый файл в системе контроля версий. Особенно те, которые должны быть сгенерированы разработчиком. Мне также нравится сохранять другие двоичные файлы, такие как изображения и PDF-файлы, в архиве и храниться в другом месте для каждого тега / выпуска.

Джереми Хейлер
источник
0

Нет, но наш внутренний инструмент управления проектами делает это автоматически, что раздражает меня.

Мое решение состоит в том, чтобы пометить все файлы в выпуске и отладке как доступные для записи, и когда TFS жалуется, я говорю об этом, чтобы игнорировать файлы, чтобы у меня никогда не возникало проблем при сбое сборки.

Доминик Макдоннелл
источник
0

Я избегаю вводить их в систему контроля версий. Это избыточная информация, двоичные файлы могут быть собраны из исходного кода в этой ревизии. Кроме того, исходный код всегда актуален, сборка может не выполняться.

Malfist
источник
0

Я сохраняю некоторые сгенерированные двоичные файлы, такие как .NET-взаимодействия из другого проекта. Поэтому, если у меня есть проект A, который создает COM-объект, а затем вы используете этот COM-объект в очень слабо связанном проекте B, который использует его через взаимодействие .NET, я отмечаю это взаимодействие, сгенерированное из проекта A, в проект B. не очень хорошая идея, но она должна куда-то идти, потому что AFAIK Visual Studio не будет автоматически создавать взаимодействие для вас во время сборки.

MK01
источник
-2

На мой взгляд, не хранение двоичных файлов в системе контроля версий является одной из самых распространенных ошибок. Они должны храниться, иметь версии, исходные данные / маркироваться вместе с источниками, а также средствами сборки. Соберите себя, создав не отслеживаемое программное обеспечение ...

QbA
источник
5
Вы высказали свое мнение, но не дали нам никаких причин, почему это хорошая практика. Кто-то, заинтересованный в этой теме, получит мало пользы от этого ответа без дополнительной поддержки.
Уолтер