На работе(C#) используется svn и общая кодовая база для разработки проектов /trunk/projects .
т.е. в trunk лежат все общие проекты и солюшены, которые собираются из [исходников] проектов, т.е. артефакты типа нугет или dll не используются.

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

У кого как в компании организован процесс разработки, ежели не секрет?

В литературе которая мне попадалась чаще речь идет о структуре /project/trunk
то же касается и гита.

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

Здравствуйте, vaa, Вы писали:

vaa>На работе(C#) используется svn и общая кодовая база для разработки проектов /trunk/projects .
vaa>т.е. в trunk лежат все общие проекты и солюшены, которые собираются из [исходников] проектов, т.е. артефакты типа нугет или dll не используются.

vaa>Мне кажется такая модель не совсем удобна для разработки большого количества по и их модификаций.

vaa>У кого как в компании организован процесс разработки, ежели не секрет?

vaa>В литературе которая мне попадалась чаще речь идет о структуре /project/trunk
vaa>то же касается и гита.
Мне кажется, что стоит отталкиваться от того, как у вас принято работать с зависимостями между проектами.
Если то, что попадает в проект достаточно стабильно для того, чтобы сразу использоваться, то ваша модель не такая уж и плохая: как вам уже ответили, затраты на поддержку общих библиотек в порядке могут быть слишком дорогими.

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

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

Другой проект был некоторым образом связан с Ms office и он плагинами подключал к себе проекты из половины майкрософта, потому у себя мы держали только core и просили всех партнёров коммитить скомпилированные бинарники к нам в отдельную директорию, что позволяло нам как следует управлять версиями и релизить их по стадиям (это было для нас принципиально).

Здравствуйте, Osaka, Вы писали:

vaa>>артефакты типа нугет или dll не используются
O>И не надо. Оно быстро разрастается в огромное нугетоводческое хозяйство, которое постоянно глючит, и обслуживание проблем нугетов начинает занимать чуть ли не больше времени, чем решение задачи за которую платит заказчик.

Я использовал нугет-пакеты в разработке. Выгода есть но не большая.