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

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

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

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

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

например:

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

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

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

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

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

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

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

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

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

a.dll

b.dll

c.dll

д'.СЅ

e.dll

... ... ...

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

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

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

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

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

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

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

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

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

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

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

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

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