Должен ли я добавлять скомпилированные двоичные файлы в мой репозиторий Subversion?

Ответ 1

Вы, конечно же, не должны добавлять какие-либо скомпилированные файлы в основную ветку. Вы не можете сравнивать их с обычными инструментами, и они будут замедлять все.

В ветках версий выпусков вы можете включить их в исходные скомпилированные файлы, чтобы не было разницы, потому что компилятор изменился или что-то вроде этого. Но вы, скорее всего, будете иметь все двоичные версии, хранящиеся где-то в другом месте, а Subversion - не самое подходящее место.

Ответ 2

Мое правило состоит в том, что все сгенерированные файлы исключены.

Ответ 3

Я могу понять, почему вы МОЖЕТЕ хотеть совершать блокировки, например, если у вас есть разные версии приложения, которое необходимо поддерживать, для которых требуются определенные версии DLL. Но даже в этом случае вы всегда можете создавать новые бункеры из тега/ветки.

Что касается фиксации файлов obj, я не могу придумать никаких оснований для этого.

Ответ 4

Я бы не добавлял скомпилированные библиотеки в исходный код, если у вас нет исходного кода.

Например:

Сторонние библиотеки/элементы управления, для которых у меня нет источника = Go в Source Control в какой-то папке "Зависимости".

Любые библиотеки, которые мы пишем = Только источник находится в репозитории, а не в двоичных файлах.

Ответ 5

Обычно я никогда не привязываю каталог bin к исходной системе управления. Причина в том, что он должен быть автоматически воспроизводимым, и поэтому нет никакого значения для добавления сгенерированных DLL в исходный элемент управления.

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

Если вы хотите управлять разными версиями, подход к ветки был бы моим любимым.

Ответ 6

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

Я предполагаю, что у вас может быть отдельная папка для "завершенных библиотек DLL" или что-то еще, если это готовая версия dll??

Ответ 7

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

Итак, представьте, что вы пытаетесь проверить, что пошло не так в версии XYZ, и вы видите в следующих изменениях:

A.DLL

B.dll

c.dll

d.cs

e.dll

... ... ...

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

Ответ 8

Если нет веской причины, о которой вы не указали, то нет, не добавляйте свои каталоги bin в исходное управление. Я не вижу никаких оснований для фиксации ваших каталогов obj.

Ответ 9

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

Мы используем Maven для создания наших проектов Subversion. В maven все исполняемые файлы, необходимые вашему приложению (но не созданные вашим приложением), хранятся вне подрывной деятельности в том, что называется репозиторием Maven. Maven использует соглашения для присоединения "версии" к двоичным файлам, используемым приложениями. Эти файлы легко разделяются приложениями и разработчиками (1 экземпляр для всех).

Ответ 10

Единственный случай, когда я видел, что имеет значение, находится в n-уровневом приложении, где некоторые двоичные файлы распределяются из одного уровня в другой.

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

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

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

Ответ 11

Мы не создаем папки bin или obj, и мы использовали для создания новой папки в корневом каталоге репозитория, называемом библиотекой, и мы помещаем туда все важные файлы dll, такие как используемые сторонние инструменты, например ajaxtoolkit, fckeditor,.... и другие DLL файлы, мы видим, что это важно для этого проекта.

Ответ 12

Хорошо, пусть играет адвокат дьявола... вот случай хранения DLL в репозитории.

Компания A имеет 6+ команд в любой момент времени. Большинство из этих команд разрабатывают хотя бы часть своего продукта на С#. Учитывая специфику компании A, стандартные классы DateTime не имеют достаточной функциональности, поэтому они разработали свои собственные классы, полученные из DateTime, которые они предоставляют в DLL.

Каждая из групп 6+ имеет свой собственный каталог в репозитории, и большинство из них требуют библиотеки DateTime DLL, поэтому у них есть копия скомпилированных библиотек DLL в каждом каталоге продуктов и нажимают новые копии в каталог только тогда, когда есть новая функциональность доступный для проекта в этом каталоге.

Есть ли другое решение, которое дает следующие преимущества?: 1) Запрещает разработчикам проверять два каталога для работы над одним проектом. (В реальной жизни их более двух, но ради этого примера позвоним ему два.) 2) Предотвращает от QA повторную проверку всех продуктов, когда только один продукт должен изменить классы DateTime.