Я должен добавить скомпилированные двоичные файлы к своему репозиторию Подверсии?

Well, let's play devil's advocate... here's a case for storing DLL's in a repository.

Company A has 6+ teams at any given point in time. Most of these teams develop at least some part of their product in C#. Given the specific nature of Company A, the standard DateTime classes don't have enough functionality, so they have developed their own classes derived from DateTime which they make available in a DLL.

Each of the 6+ groups has its own directory in the repository and most require the DateTime DLLs, so they have a copy of the compiled DLLs in each product directory, and push new copies to a directory only when there is new functionality available that the project in that directory requires.

Is there another solution that gives the following benefits?: 1) Запрещает разработчикам проверять две директории для работы над одним проектом. (В реальной жизни их больше двух, но для примера рассмотрим два.) 2) Предотвращает QA от необходимости повторного тестирования всех продуктов, когда только один продукт должен изменить классы DateTime.

I try not to store any binaries in our source control system - not even libraries where we don't have the source. Having the binaries in the repository bloats the repository and makes checkouts slow.

We use Maven to build our Subversion projects. In maven, all binaries needed by your application (but not created by your app) are stored outside subversion in what's called a Maven repository. Maven uses conventions to attach a "version" to binary files used by applications. These files are easily shared by applications and developers (1 copy for everyone).

The only case where I have seen that have value is in an n-tier application where some binaries are distributed from one tier to another.

For example, part of the code represents common objects used by all tiers. Then each tier is really its own sub-project that uses the common objects referenced as binaries, but working on that tier alone relies just on the binary. In that case, even though in the project as a whole the source code is there, in fact a binary is a part of the project, like a third party library in a way.

In that case it may make sense to make sure that the tier continues to compile successfully by freezing the right version of the binary in source control, and not always building from the source.

That being said, life will be a lot easier if you can void that paradigm, and include all dependencies in the build of each tier. Having the binaries of one part of the project behind the source in another is not pretty and can lead to disaster.

We don't commit bin or obj folders, and we used to create a new folder on the repository root called library and we put there all important dll files, such as the used third party tools, for example ajaxtoolkit, fckeditor,.... and and other dll files we see its important for this project.

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

Например:

Сторонние библиотеки / элементы управления, для которых у меня нет the source = Перейти в Source Control в какую-то папку «Зависимости».

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

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

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

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

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

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

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

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

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

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

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

a.dll

b.dll

c.dll

d.cs

e.dll

... ... ...

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

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