Для MSVC, под виндами, С#, winforms, если что.
Временами на работе возникают дискуссии, что подключать лучше в солюшин как внешние ссылки при наличии исходников — DLL-ки или проекты.
Понятно что абсолютно однозначного ответа нет, зависит от конкретной ситуации. Допустим, когда исходники стабильные и практически не меняются, либо от кого-то другого, то видимо DLL-ки с PDB (и отдельными исходниками для отладки) лучше. По крайней мере, нет никакой возможности изменить непреднамеренно код.

Речь же идет исключительно об исходниках текущего проекта, собираемого из многих подпроектов. Просто часто сталкивался, когда исходники чуть чуть отличаются от ДЛЛ-ки и фиг поймешь отчего вдруг не работает/вылетает. Хотя некоторые имеют мнение, что при наличии решарпера и многих разработчиков лучше пользовать исключительно ДЛЛ-ки, несмотря на наличие в солюшин всех требуемы подпроектов с исходниками. А то что кто то забудет актуальную версию загрузить, нужно регулировать постановлениями партии и правительства
Хотелось бы услышать различные мнения за и против каждого из подходов, чтобы не ругатся до состояния "пены у рта".

ИМХО чаще подключается DLL. Навскидку приходят такие минусы подключения исходников стороннего проекта:
— Скорее всего исходников подключаемого проекта не окажется в репозитории, что может оказаться проблемой при checkout'е на другом/чистом компьютере
— Если хранить подключаемые проекты в репозитории, то это увеличивает размер репозитория (а необходимость подключения стороннего проекта через исходники может быть сомнительна)
— Увеличится время компиляции проекта
— Возможно, что нужна стабильная версия подключаемого проекта. Допустим, я в своем проекте А использую проект Васи — Б (может и сам в нем тоже участвую), проект Васи Б тоже под контролем версий у меня. Тогда, если вдруг Вася что-то изменит в проекте Б, а я сделаю update проекта Б, то в моем проекте А может что-то поломаться или придется что-то менять.

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

AN>Временами на работе возникают дискуссии, что подключать лучше в солюшин как внешние ссылки при наличии исходников — DLL-ки или проекты.

В разных случаях нужно по-разному.

Расскажу, как можно подключать через исходники на примере использования Mercurial. Для этого создаются репозитории-модули с исходниками/ассетами и один или несколько тонких мастер-репозиториев, содержащих только sln-файлы, файл .hgsub со списком модулей-субрепозиториев и .hgsubstate с информацией о чейнджсетах субрепозиториев, ассоциированных с текущим состоянием мастер-репозитория.

Скажем, у тебя есть проект MyProduct.Core, который используется твоим проектом MyProduct.Client и проектом MyProduct.Server, над которым независимо работают коллеги. Создаёшь два мастера:

MyProduct.Client.Master/
  MyProduct.Core/
  MyProduct.Client/
  MyProduct.Client.sln
  .hgsub
  .hgsubstate

и аналогично для MyProduct.Server.Master/.

Если кто-то, работая над сервером, внесёт изменения в MyProduct.Core (скажем, обновит его до версии 3.5.0.128), то у тебя в клиенте ничего не сломается, потому что мастер-репозиторий для клиента всё ещё нацелен на предыдущий рабочий чейнджсет подпроекта MyProduct.Core (скажем, 3.4.0.125). Можешь продолжать работать со своей версией. Видя что в субрепозиторий пришли новые чейнджсеты, в удобное для себя время можешь обновить рабочую папку до актуальной версии и восстановить работоспособность своего клиента.

Относительно другого косвенно затронутого вопроса. По dll'кам всегда должна быть возможность восстановить идентификатор чейнджсета или хотя бы номер ревизии исходников, из которых библиотека была собрана. Первое можно вшить в dll'ку кастомным атрибутом, второе — прямо в последний компонент версии (см. стандартные атрибуты AssemblyVersion, AssemblyFileVersion, AssemblyInformationalVersion).

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

AN>Речь же идет исключительно об исходниках текущего проекта, собираемого из многих подпроектов. Просто часто сталкивался, когда исходники чуть чуть отличаются от ДЛЛ-ки и фиг поймешь отчего вдруг не работает/вылетает. Хотя некоторые имеют мнение, что при наличии решарпера и многих разработчиков лучше пользовать исключительно ДЛЛ-ки, несмотря на наличие в солюшин всех требуемы подпроектов с исходниками. А то что кто то забудет актуальную версию загрузить, нужно регулировать постановлениями партии и правительства
AN>Хотелось бы услышать различные мнения за и против каждого из подходов, чтобы не ругатся до состояния "пены у рта".

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

Зато факт, что используемый реально код не соответствует исходникам вызывает бешенную ненависть после кучи времени потраченного на детект ситауции. А оно вам надо? И зачем вообще тратить время на загрузки "актуальных версий"?

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

Q>В разных случаях нужно по-разному.

Ещё рассмотри вариант создавать бинарные NuGet-пакеты, заливаемые на доступный всем разработчикам источник. Все работают со своими (строго определёнными) версиями бинарников, и могут при желании проапдейтится со стабильных до текущих версий. Потом поделись опытом, плюсы, минусы, подводные грабли.

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

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

AN>Для MSVC, под виндами, С#, winforms, если что.
AN>Временами на работе возникают дискуссии, что подключать лучше в солюшин как внешние ссылки при наличии исходников — DLL-ки или проекты.

ИМХО, однозначно только использовать подключение библиотек.
Назовем ради примера:
общая часть — сервер,
пользователи общей части — клиенты.

Минус только один — увеличивается время внесения изменений в сервер и процесс уведомления клиентов, чтобы они заюзали обновленную версию сервера
(это даже еще не означает что они должны немедленно использовать обновление).
Плюсы:

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

Версионирование сервера — возможность для разных клиентов юзать разные версии сервера

Время на внесение изменений в клиент с использованием стабильной версии сервера всегда фиксированно и не имеет рисков из-за сервера

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

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

A_A>Плюсы:

Перечисленных плюсов можно добиться и ссылаясь на исходники.

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

A_A>ИМХО, однозначно только использовать подключение библиотек.
хъ
Это все прекрасно делается с нормальными системами контроля версий

Автор: Qbit86
Дата: 19.11.11

.
Поставь git или hg и будет тебе счастье.

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

A_A>Минус только один

Минус не только один. Среди прочих:

К задаче версионирования и публикации исходников добавляется задача версионирования и доставки разработчикам производных артефактов.

Проще отлаживать, когда исходники рядышком.

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

MC>ИМХО чаще подключается DLL.
Я лично сталкивался чаще с обратным, причем часто вначале подключали Длл-ки, а после затыкав переходили на проекты.
MC>Навскидку приходят такие минусы подключения исходников стороннего проекта:
MC>- Скорее всего исходников подключаемого проекта не окажется в репозитории, что может оказаться проблемой при checkout'е на другом/чистом компьютере
В обсуждаемом варианте они всегда есть.
MC>- Если хранить подключаемые проекты в репозитории, то это увеличивает размер репозитория (а необходимость подключения стороннего проекта через исходники может быть сомнительна)
размер бинарниками будет несравненно больше, вес проекты "свои".
MC>- Увеличится время компиляции проекта
Только первый раз, да и нет сотни гигантских подпроектов.
MC>- Возможно, что нужна стабильная версия подключаемого проекта. Допустим, я в своем проекте А использую проект Васи — Б (может и сам в нем тоже участвую), проект Васи Б тоже под контролем версий у меня. Тогда, если вдруг Вася что-то изменит в проекте Б, а я сделаю update проекта Б, то в моем проекте А может что-то поломаться или придется что-то менять.
Вообще то это и нужно как можно раньше определить. Или иначе, нельзя тогда вообще иметь исходников других продключаемых проектов.
Если исходники Васи все же пользуются, а они не будут совпадать с Длл-ков, то последствия могут быть непредсказуемыми.
А несовпадение довольно просто. Или мы забыли взять последнюю версию всего или Вася забыл обновить библиотеку или обновил не на последнюю версию.

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

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

AN>>Временами на работе возникают дискуссии, что подключать лучше в солюшин как внешние ссылки при наличии исходников — DLL-ки или проекты.

Q>В разных случаях нужно по-разному.
Да — это понятно. Хотелось бы иметь что то типа рекомендаций/статистики по часто используемым случаям. Мои аргументы уже все исчерпались.

Q>Расскажу, как можно подключать через исходники на примере использования Mercurial.
Есть только SVN.


Q>Относительно другого косвенно затронутого вопроса. По dll'кам всегда должна быть возможность восстановить идентификатор чейнджсета или хотя бы номер ревизии исходников, из которых библиотека была собрана. Первое можно вшить в dll'ку кастомным атрибутом, второе — прямо в последний компонент версии (см. стандартные атрибуты AssemblyVersion, AssemblyFileVersion, AssemblyInformationalVersion).
Во время разработки обычно никто после изменения пары строчек не меняет номер версии. Это прерогатива "выпускающего"

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

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

AN>>Речь же идет исключительно об исходниках текущего проекта, собираемого из многих подпроектов. Просто часто сталкивался, когда исходники чуть чуть отличаются от ДЛЛ-ки и фиг поймешь отчего вдруг не работает/вылетает. Хотя некоторые имеют мнение, что при наличии решарпера и многих разработчиков лучше пользовать исключительно ДЛЛ-ки, несмотря на наличие в солюшин всех требуемы подпроектов с исходниками. А то что кто то забудет актуальную версию загрузить, нужно регулировать постановлениями партии и правительства
AN>>Хотелось бы услышать различные мнения за и против каждого из подходов, чтобы не ругатся до состояния "пены у рта".

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

Z>Зато факт, что используемый реально код не соответствует исходникам вызывает бешенную ненависть после кучи времени потраченного на детект ситауции.
На это отвечают — прищучим всех Во что слабо верится.
Z>А оно вам надо? И зачем вообще тратить время на загрузки "актуальных версий"?
Аргументируют, что Длл-ку имеет право изменить только "автор". А при наличии исходников, кто угодно. В результате локальная версия может не совпадать с конечной.
Хотя если все билдится из репозитория, то это уже относительно простая проблема разработчика не иметь изменений в "чужих" проектах. При чекине видно на раз.

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

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

Q>>В разных случаях нужно по-разному.

Q>Ещё рассмотри вариант создавать бинарные NuGet-пакеты, заливаемые на доступный всем разработчикам источник. Все работают со своими (строго определёнными) версиями бинарников, и могут при желании проапдейтится со стабильных до текущих версий. Потом поделись опытом, плюсы, минусы, подводные грабли.
Кто будет их создавать и когда? А также когда их брать? А будет ли обеспечено, что исходники всех разработчиков будут точно сообтветствовать бинарникам.
Допустим в 16:00 создали либы по репозиторию, а в 16:15 кто то залил изменения в репозиторий. В итоге те кто возьмут пакет и обновление репозитория в 16:20 получат несоответсвие.

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

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

A_A>>Плюсы:

Q>Перечисленных плюсов можно добиться и ссылаясь на исходники.

Пример:
Нужно внести в клиент срочные минорные изменения.
Естимейты — 1 день с рисками и тестами.

Вносим -> поломали сервер -> чиним сервер -> поломали клиента...

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

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

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

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

A_A>>ИМХО, однозначно только использовать подключение библиотек.
WH>хъ
WH>Это все прекрасно делается с нормальными системами контроля версий

Автор: Qbit86
Дата: 19.11.11

.
WH>Поставь git или hg и будет тебе счастье.

SVN тоже позволяет подключать исходники как SVN:externals.
Система контроля версий здесь непричем.

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

Q>>Расскажу, как можно подключать через исходники на примере использования Mercurial.
AN>Есть только SVN.

Можно пристально посмотреть в сторону svn:externals. И вообще, повлиять на руководство в сторону приобщения к правильным и удобным инструментам.

AN>Во время разработки обычно никто после изменения пары строчек не меняет номер версии. Это прерогатива "выпускающего"

Версии (major, minor, maintenance) — да. А номер build'а (у нас это номер ревизии того локального клона репозитория, с которого идёт сборка на билд-сервере; нужна только для удобства) и атрибут с чейнджсетом (скажем, 111c07b94e72, для уникальной идентификации) — добавляются автоматически. Т.е. поддержания обратного маппинга (от бинарника dll'ки к версии исходников) происходит без участия человеков типа «выпускающего».

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

AN>Кто будет их создавать и когда?

Непрерывная интеграция на билд-сервере, конечно.

AN>А также когда их брать?

Когда угодно. У тебя стоит ссылка на пакет версии 3.4.0.128. То, что на билд-сервере появляются версии 3.4.0.129, 3.4.0.130, etc твою программу не ломает. То же, что и со сторонними библиотеками. Скажем, используешь ты NUnit 2.5.9.10348. То, что вышла новая версия NUnit 2.5.10.11092 никоим образом на твою программу повлиять не может, пока ты сам не решишь обновиться.

AN>А будет ли обеспечено, что исходники всех разработчиков будут точно сообтветствовать бинарникам.

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

AN>Допустим в 16:00 создали либы по репозиторию, а в 16:15 кто то залил изменения в репозиторий. В итоге те кто возьмут пакет и обновление репозитория в 16:20 получат несоответсвие.

Нет, они продолжают использовать пакет от 16:00. Всё собирается, работает. Но могут нажать кнопку Update Packages, когда готовы начать разрешать потенциально появившиеся конфликты из-за отсутствия обратной совместимости версий разрабатываемой переиспользуемой библиотеки.

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

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

AN>>Для MSVC, под виндами, С#, winforms, если что.
AN>>Временами на работе возникают дискуссии, что подключать лучше в солюшин как внешние ссылки при наличии исходников — DLL-ки или проекты.

A_A>ИМХО, однозначно только использовать подключение библиотек.
A_A>Назовем ради примера:
A_A>общая часть — сервер,
A_A>пользователи общей части — клиенты.
То есть пример практически не связанного кода. Максимум — протоколы обмена, видимо.
А что если класс Б наследуется от А и они в разным проектах?

A_A>Минус только один — увеличивается время внесения изменений в сервер и процесс уведомления клиентов, чтобы они заюзали обновленную версию сервера
То бишь сервер не у разработчика локально?

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

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

A_A>>ИМХО, однозначно только использовать подключение библиотек.
WH>хъ
WH>Это все прекрасно делается с нормальными системами контроля версий

Автор: Qbit86
Дата: 19.11.11

.
WH>Поставь git или hg и будет тебе счастье.
Увы, но система контроля версий не может менятся локально для команды. Многие процессы уже завязаны на конкретную систему.

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

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

A_A>>Минус только один

Q>Минус не только один. Среди прочих:
Q>

К задаче версионирования и публикации исходников добавляется задача версионирования и доставки разработчикам производных артефактов.
Q>

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

Cообщение написано в << RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461>>

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

A_A>ссылки на версионированные библиотеки являются защитой от этих возможных рисков в будущем.

У тебя ссылки на версионированные исходники.

A_A>Пример:
A_A>Нужно внести в клиент срочные минорные изменения.
A_A>Естимейты — 1 день с рисками и тестами.

A_A>Вносим -> поломали сервер

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

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

Q>>Ещё рассмотри вариант создавать бинарные NuGet-пакеты, заливаемые на доступный всем разработчикам источник. Все работают со своими (строго определёнными) версиями бинарников, и могут при желании проапдейтится со стабильных до текущих версий. Потом поделись опытом, плюсы, минусы, подводные грабли.
AN>Кто будет их создавать и когда? А также когда их брать? А будет ли обеспечено, что исходники всех разработчиков будут точно сообтветствовать бинарникам.
AN>Допустим в 16:00 создали либы по репозиторию, а в 16:15 кто то залил изменения в репозиторий. В итоге те кто возьмут пакет и обновление репозитория в 16:20 получат несоответсвие.

А кто будет вообще писать код и когда?

Ответ очевиден — тот, кому будут платить за это деньги.
Варианта как минимум два:
1) Если нет человека с такой должностью — нужно завести должность и взять человека
2) Совмещать кому-то из существующих

Брать тогда, когда нужна новая функциональность.
На каждую версию создавать ветки в СВН — если хочешь чтобы код соответствовал бинарникам(в моей практике это было не нужно).

Извини, но с таким подходом к разработке надо улучшать процессы разработки.
Создается новая версия библиотеки -> она выкладывается куда-то в шару -> делается описание внесенных изменений -> идут уведомления клиентам о новой версии.

Клиенты сами решают юзать или нет новую версию.

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

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

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

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

AN>Аргументируют, что Длл-ку имеет право изменить только "автор". А при наличии исходников, кто угодно. В результате локальная версия может не совпадать с конечной.
AN>Хотя если все билдится из репозитория, то это уже относительно простая проблема разработчика не иметь изменений в "чужих" проектах. При чекине видно на раз.

Поддерживаю этот аргумент.

Пример:
Девелопер меняет клиента -> ломается сервер -> этот же девелопер чинит исходники сервера(которые находятся как ссылка) -> все работает.

В 70% случаев в такой ситуации изменения в сервере будут "на скорую руку", т.е. будет сделан "костыль" чтобы закрыть таску по изменениям в клиенте.
Т.е. теоретически изменения будет вносить человек, который не знает структур проекта сервера достаточно хорошо, чтобы внести "правильные" изменения.

В этом случае ссылки на библиотеки будут защитой от таких возможных последствий в сервере.

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

A_A>>ИМХО, однозначно только использовать подключение библиотек.
A_A>>Назовем ради примера:
A_A>>общая часть — сервер,
A_A>>пользователи общей части — клиенты.
AN>То есть пример практически не связанного кода. Максимум — протоколы обмена, видимо.
Отнюдь не только. Библиотеки .NET Framework — это связанный код с твоими проектами или нет?
AN>А что если класс Б наследуется от А и они в разным проектах?
Нет проблем. Ты наследовался от классов из .NET Framework?

A_A>>Минус только один — увеличивается время внесения изменений в сервер и процесс уведомления клиентов, чтобы они заюзали обновленную версию сервера
AN>То бишь сервер не у разработчика локально?
Как получить сервер на клиенте — это уже другой вопрос

Мы юзаем тоже NuGet — впечатления отличные, полет нормальный

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

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

A_A>>ссылки на версионированные библиотеки являются защитой от этих возможных рисков в будущем.

Q>У тебя ссылки на версионированные исходники.

A_A>>Пример:
A_A>>Нужно внести в клиент срочные минорные изменения.
A_A>>Естимейты — 1 день с рисками и тестами.

A_A>>Вносим -> поломали сервер

Q>Поломали сервер в своей ветке. Остальные клиенты продолжают использовать стабильную версию исходников сервера, как в случае, если бы они ссылались на предыдущую версию бинарника сервера.

Если на любые изменения в сервере делать ветки в СКВ и менять ссылки у клиентов на новый урл, то да — в данной ситуации различий нет.

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

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

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

Q>У тебя есть ссылка на dll'ку, методы в которой хочешь пройти пошагово. Но у тебя нет PDB. Значит его нужно отдельно собрать из исходников. Т.е. опять же решить проблему, какая версия исходников соответствовала той версии dll'ки, на которую у тебя ссылка.

Поставлять PDB вместе с DLL.
Мы так и делаем — в NuGet пакете PDB вместе с DLL.

А при релиз-билде все PDB будут отсутствовать.

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

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

Q>>>Расскажу, как можно подключать через исходники на примере использования Mercurial.
AN>>Есть только SVN.

Q>Можно пристально посмотреть в сторону svn:externals.
Админ, блин подключил так дев ехпресс, так теперь в каждом проекте своя копия. Ужас просто.
Q>И вообще, повлиять на руководство в сторону приобщения к правильным и удобным инструментам.
Для этого нужно полностью менять/перестраивать все сопутствующее окружение которое настраивалось и подключалось разными людьми в течении многих лет.

AN>>Во время разработки обычно никто после изменения пары строчек не меняет номер версии. Это прерогатива "выпускающего"

Q>Версии (major, minor, maintenance) — да. А номер build'а (у нас это номер ревизии того локального клона репозитория, с которого идёт сборка на билд-сервере; нужна только для удобства) и атрибут с чейнджсетом (скажем, 111c07b94e72, для уникальной идентификации) — добавляются автоматически. Т.е. поддержания обратного маппинга (от бинарника dll'ки к версии исходников) происходит без участия человеков типа «выпускающего».
Так а "подключение" исходников по чейнджсету происходит также?

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

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

AN>>А также когда их брать?

Q>Когда угодно. У тебя стоит ссылка на пакет версии 3.4.0.128. То, что на билд-сервере появляются версии 3.4.0.129, 3.4.0.130, etc твою программу не ломает. То же, что и со сторонними библиотеками. Скажем, используешь ты NUnit 2.5.9.10348. То, что вышла новая версия NUnit 2.5.10.11092 никоим образом на твою программу повлиять не может, пока ты сам не решишь обновиться.
Во внутренности NUnit мне не нужно лезть. Допустим получил я от библииотеке 0, а должно быть 5. Лезешь с отладкой и видишь что 0 ну никак не может получится. А это просто версии исходников и либы не совпадают.

AN>>А будет ли обеспечено, что исходники всех разработчиков будут точно сообтветствовать бинарникам.

Q>Не понял вопрос. Твоя переиспользуемая библиотека теперь выглядит так же, как не твоя переиспользуемая библиотека. От которой у тебя нет, и не нужны исходники. Все проекты всегда ссылаются на точную версию строгоименованной библиотеки.
Кажется, я уловил проблему. Все будет работать когда ВСЕ проекты подключены как Длл-ки (исключая вариант с отладкой кода). Но если я разработчик и мне нужно иметь актуальную версию Длл-ки, то их получается уже две версии. Одна собранная по исходникам, другая из репозитория. Дя какого-то небольшого количества еще можно все отследить, но когда и тех и других достаточно много да и еще со сложными зависимостями, остается только ждать накладки.
Должен быть всегда один источник и смешанная работа просто не допускается. Или всегда абсолютно все свои текущие проекты как Длл-ки с сервера или все подключения через проекты (кроме чисто библиотечных, считаемых как бы не своими). То есть если есть иерархия проектов, то вся ветка либо/либо, но никак не комбинация в ветке.

AN>>Допустим в 16:00 создали либы по репозиторию, а в 16:15 кто то залил изменения в репозиторий. В итоге те кто возьмут пакет и обновление репозитория в 16:20 получат несоответсвие.

Q>Нет, они продолжают использовать пакет от 16:00. Всё собирается, работает. Но могут нажать кнопку Update Packages, когда готовы начать разрешать потенциально появившиеся конфликты из-за отсутствия обратной совместимости версий разрабатываемой переиспользуемой библиотеки.
То бишь к бинаркам жестко привязаны исходники и наоброт?

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

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

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

A_A>>>ссылки на версионированные библиотеки являются защитой от этих возможных рисков в будущем.

Q>>У тебя ссылки на версионированные исходники.

A_A>>>Пример:
A_A>>>Нужно внести в клиент срочные минорные изменения.
A_A>>>Естимейты — 1 день с рисками и тестами.

A_A>>>Вносим -> поломали сервер

Q>>Поломали сервер в своей ветке. Остальные клиенты продолжают использовать стабильную версию исходников сервера, как в случае, если бы они ссылались на предыдущую версию бинарника сервера.

A_A>Если на любые изменения в сервере делать ветки в СКВ и менять ссылки у клиентов на новый урл, то да — в данной ситуации различий нет.

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

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

A_A>SVN тоже позволяет подключать исходники как SVN:externals.
Он много что позволяет, но все через задний проход с массой геморроя.

A_A>Система контроля версий здесь непричем.
Еще как причем.
Чтобы так работать нужно постоянно делать бранчи.
Ибо когда правишь код во внешнем модуле, сразу же должен создаваться новый бранч для этого кода.
А потом уже его будут в спокойной обстановке сливать с основным кодом.
А в SVN с бранчами страшный геморрой.

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

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

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

Q>>>>Расскажу, как можно подключать через исходники на примере использования Mercurial.
AN>>>Есть только SVN.

Q>>Можно пристально посмотреть в сторону svn:externals.
AN>Админ, блин подключил так дев ехпресс, так теперь в каждом проекте своя копия. Ужас просто.
На сервере лежит только одна копия исходников, а на клиенте — да, на каждый svn:externals плюс одна локальная копия.
Почему ужас-то? Места на диске не хватает?
Q>>И вообще, повлиять на руководство в сторону приобщения к правильным и удобным инструментам.
AN>Для этого нужно полностью менять/перестраивать все сопутствующее окружение которое настраивалось и подключалось разными людьми в течении многих лет.
Идешь к руководству с аргументами типа: после этих изменений мы будем меньше тратить времени на разработку -> и тут варианты:

время на разработку уменьшится — экономия бабла для заказчика

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

система будет более стабильна(будет меньше возможных багов) — вероятность потери клиентов для заказчика снизится — заказчик будет меньше терять бабла

С такими аргументами нормальное руководство утверждает.

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

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

A_A>>SVN тоже позволяет подключать исходники как SVN:externals.
WH>Он много что позволяет, но все через задний проход с массой геморроя.

A_A>>Система контроля версий здесь непричем.
WH>Еще как причем.
WH>Чтобы так работать нужно постоянно делать бранчи.
WH>Ибо когда правишь код во внешнем модуле, сразу же должен создаваться новый бранч для этого кода.
А какая СКВ позволяет делать это автоматически?
WH>А потом уже его будут в спокойной обстановке сливать с основным кодом.
Не обязательно.
Наша общая часть в отдельном репозитории на СКВ.
На ней настроена билд конфигурация.

Я хочу сделать новую версию общей части для одного клиента:
1)Коммичу код — запускаю билд с таргетом "Deploy" — автоматически создается новая версия NuGet пакета.
По версии библиотеки (major.minor[.build[.revision]]) я всегда найду исходники и автора изменений.
Подключаю новую версию библиотеки на клиенте.
никаких бранчей и мерджев.
Иду пить пиво

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

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

A_A>>SVN тоже позволяет подключать исходники как SVN:externals.
WH>Он много что позволяет, но все через задний проход с массой геморроя.

A_A>>Система контроля версий здесь непричем.
WH>Еще как причем.
WH>Чтобы так работать нужно постоянно делать бранчи.
WH>Ибо когда правишь код во внешнем модуле, сразу же должен создаваться новый бранч для этого кода.
WH>А потом уже его будут в спокойной обстановке сливать с основным кодом.
WH>А в SVN с бранчами страшный геморрой.

В предыдущем ответе я немного тебя не понял и ответил явно не по теме.

В изначальном посте о необходимости версионирования исходников не было сказано,
поэтому вариант с подключением сорцов из транка как SVN:externals является нормальным.

А на вопрос версионирования и мерджев в SVN — это да, геморрой еще тот

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

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

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

AN>>>А также когда их брать?

Q>>Когда угодно. У тебя стоит ссылка на пакет версии 3.4.0.128. То, что на билд-сервере появляются версии 3.4.0.129, 3.4.0.130, etc твою программу не ломает. То же, что и со сторонними библиотеками. Скажем, используешь ты NUnit 2.5.9.10348. То, что вышла новая версия NUnit 2.5.10.11092 никоим образом на твою программу повлиять не может, пока ты сам не решишь обновиться.
AN>Во внутренности NUnit мне не нужно лезть. Допустим получил я от библииотеке 0, а должно быть 5. Лезешь с отладкой и видишь что 0 ну никак не может получится. А это просто версии исходников и либы не совпадают.
Нужно собирать либу с такой версией, чтобы можно было найти реальные исходники.

AN>>>А будет ли обеспечено, что исходники всех разработчиков будут точно сообтветствовать бинарникам.

Q>>Не понял вопрос. Твоя переиспользуемая библиотека теперь выглядит так же, как не твоя переиспользуемая библиотека. От которой у тебя нет, и не нужны исходники. Все проекты всегда ссылаются на точную версию строгоименованной библиотеки.
AN>Кажется, я уловил проблему. Все будет работать когда ВСЕ проекты подключены как Длл-ки (исключая вариант с отладкой кода). Но если я разработчик и мне нужно иметь актуальную версию Длл-ки, то их получается уже две версии. Одна собранная по исходникам, другая из репозитория. Дя какого-то небольшого количества еще можно все отследить, но когда и тех и других достаточно много да и еще со сложными зависимостями, остается только ждать накладки.
AN>Должен быть всегда один источник и смешанная работа просто не допускается. Или всегда абсолютно все свои текущие проекты как Длл-ки с сервера или все подключения через проекты (кроме чисто библиотечных, считаемых как бы не своими). То есть если есть иерархия проектов, то вся ветка либо/либо, но никак не комбинация в ветке.
Да. перемешивать нельзя — бардак будет еще тот.

AN>>>Допустим в 16:00 создали либы по репозиторию, а в 16:15 кто то залил изменения в репозиторий. В итоге те кто возьмут пакет и обновление репозитория в 16:20 получат несоответсвие.

Q>>Нет, они продолжают использовать пакет от 16:00. Всё собирается, работает. Но могут нажать кнопку Update Packages, когда готовы начать разрешать потенциально появившиеся конфликты из-за отсутствия обратной совместимости версий разрабатываемой переиспользуемой библиотеки.
AN>То бишь к бинаркам жестко привязаны исходники и наоброт?
Да.

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

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

Q>>>Ещё рассмотри вариант создавать бинарные NuGet-пакеты, заливаемые на доступный всем разработчикам источник. Все работают со своими (строго определёнными) версиями бинарников, и могут при желании проапдейтится со стабильных до текущих версий. Потом поделись опытом, плюсы, минусы, подводные грабли.
AN>>Кто будет их создавать и когда? А также когда их брать? А будет ли обеспечено, что исходники всех разработчиков будут точно сообтветствовать бинарникам.
AN>>Допустим в 16:00 создали либы по репозиторию, а в 16:15 кто то залил изменения в репозиторий. В итоге те кто возьмут пакет и обновление репозитория в 16:20 получат несоответсвие.

A_A>А кто будет вообще писать код и когда?

A_A>Ответ очевиден — тот, кому будут платить за это деньги.
A_A>Варианта как минимум два:
A_A>1) Если нет человека с такой должностью — нужно завести должность и взять человека
А зачем, когда можно вполен обойтись без него просто использую другой подход.
A_A>2) Совмещать кому-то из существующих
Совмещать несколько празличных заданий особенно в стрессе релиза чревато.

A_A>Брать тогда, когда нужна новая функциональность.
A_A>На каждую версию создавать ветки в СВН — если хочешь чтобы код соответствовал бинарникам(в моей практике это было не нужно).
Уж сколько помню всегда с этим были проблемы.

A_A>Извини, но с таким подходом к разработке надо улучшать процессы разработки.
A_A>Создается новая версия библиотеки -> она выкладывается куда-то в шару -> делается описание внесенных изменений -> идут уведомления клиентам о новой версии.
Дело не идет о библиотеке и внешних клиентах, там все по другому. Разговор о команде разрабатывающей достаточно большой проект, скажем с полтинником подпроектов. И все проиходит именно на этапе разработки.

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

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

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

Q>У тебя есть ссылка на dll'ку, методы в которой хочешь пройти пошагово. Но у тебя нет PDB. Значит его нужно отдельно собрать из исходников. Т.е. опять же решить проблему, какая версия исходников соответствовала той версии dll'ки, на которую у тебя ссылка.
PDB то будет идти с Длл-кой, но вот гарантировать совместимость исходников с ними, да проблема.
И кстати, как сгенерить PDB без DLL-ки?

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

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

AN>>Аргументируют, что Длл-ку имеет право изменить только "автор". А при наличии исходников, кто угодно. В результате локальная версия может не совпадать с конечной.
AN>>Хотя если все билдится из репозитория, то это уже относительно простая проблема разработчика не иметь изменений в "чужих" проектах. При чекине видно на раз.

A_A>Поддерживаю этот аргумент.

A_A>Пример:
A_A>Девелопер меняет клиента -> ломается сервер -> этот же девелопер чинит исходники сервера(которые находятся как ссылка) -> все работает.

A_A>В 70% случаев в такой ситуации изменения в сервере будут "на скорую руку", т.е. будет сделан "костыль" чтобы закрыть таску по изменениям в клиенте.
A_A>Т.е. теоретически изменения будет вносить человек, который не знает структур проекта сервера достаточно хорошо, чтобы внести "правильные" изменения.

A_A>В этом случае ссылки на библиотеки будут защитой от таких возможных последствий в сервере.
Значит голос за Длл-ки? А как быть тогда с совмещением ссылок на Длл-ки и проекты? Что делать разработчику именно этой Длл-ки в проекте? И что делать остальным когда исходники уже в репозитории, но бильд длл-ок еще не готов. Ждать пока не будет все готово и после все брать? А если в это же время закоммитились другие изменения, которые нужно пока избежать? (Допустим они исправили генерацию данных, и неправильные данные для теста уже получить просто невозможно) То есть нужно отслеживать два источника: исходники и бинарники, и к тому же учитывать иерархию бинарников.

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

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

A_A>>>ИМХО, однозначно только использовать подключение библиотек.
A_A>>>Назовем ради примера:
A_A>>>общая часть — сервер,
A_A>>>пользователи общей части — клиенты.
AN>>То есть пример практически не связанного кода. Максимум — протоколы обмена, видимо.
A_A>Отнюдь не только. Библиотеки .NET Framework — это связанный код с твоими проектами или нет?
А у меня есть исходники .NET Framework в проекте?

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

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

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

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

Q>>>>>Расскажу, как можно подключать через исходники на примере использования Mercurial.
AN>>>>Есть только SVN.

Q>>>Можно пристально посмотреть в сторону svn:externals.
AN>>Админ, блин подключил так дев ехпресс, так теперь в каждом проекте своя копия. Ужас просто.
A_A>На сервере лежит только одна копия исходников, а на клиенте — да, на каждый svn:externals плюс одна локальная копия.
A_A>Почему ужас-то? Места на диске не хватает?
Допустим я обновляю версию бибилотеки, но вначале чисто для теста, как будет у меня работать. Теперь вместо одной замены нужно делать Х. Либо я могу для отладки просто сбилдить Длл-ки из исходников локально. Опять надо искать механизм подмены всех версий.
Q>>>И вообще, повлиять на руководство в сторону приобщения к правильным и удобным инструментам.
AN>>Для этого нужно полностью менять/перестраивать все сопутствующее окружение которое настраивалось и подключалось разными людьми в течении многих лет.
A_A>Идешь к руководству с аргументами типа: после этих изменений мы будем меньше тратить времени на разработку -> и тут варианты:
A_A>

время на разработку уменьшится — экономия бабла для заказчика
ну это еще нужно доказать что время на разработку действительно Существенно уменьшится, в чем я несколько сомневаюсь.
A_A>

заказчик будет получать продукты быстрее — сможет выходить на рынок с новым продуктом раньше — получение новых прибылей для заказчика
A_A>

система будет более стабильна(будет меньше возможных багов) — вероятность потери клиентов для заказчика снизится — заказчик будет меньше терять бабла
Как система контроля версий влияет на количество багов?

A_A>С такими аргументами нормальное руководство утверждает.
А кто, сколько времени и на что будет перестраивать все остальное?

Cообщение написано в << RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461>>

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

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

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

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

AN>>>>А также когда их брать?

Q>>>Когда угодно. У тебя стоит ссылка на пакет версии 3.4.0.128. То, что на билд-сервере появляются версии 3.4.0.129, 3.4.0.130, etc твою программу не ломает. То же, что и со сторонними библиотеками. Скажем, используешь ты NUnit 2.5.9.10348. То, что вышла новая версия NUnit 2.5.10.11092 никоим образом на твою программу повлиять не может, пока ты сам не решишь обновиться.
AN>>Во внутренности NUnit мне не нужно лезть. Допустим получил я от библииотеке 0, а должно быть 5. Лезешь с отладкой и видишь что 0 ну никак не может получится. А это просто версии исходников и либы не совпадают.
A_A>Нужно собирать либу с такой версией, чтобы можно было найти реальные исходники.
Кто и как будет проверять версию Длл-ки при входе в функцию?

AN>>>>А будет ли обеспечено, что исходники всех разработчиков будут точно сообтветствовать бинарникам.

Q>>>Не понял вопрос. Твоя переиспользуемая библиотека теперь выглядит так же, как не твоя переиспользуемая библиотека. От которой у тебя нет, и не нужны исходники. Все проекты всегда ссылаются на точную версию строгоименованной библиотеки.
AN>>Кажется, я уловил проблему. Все будет работать когда ВСЕ проекты подключены как Длл-ки (исключая вариант с отладкой кода). Но если я разработчик и мне нужно иметь актуальную версию Длл-ки, то их получается уже две версии. Одна собранная по исходникам, другая из репозитория. Дя какого-то небольшого количества еще можно все отследить, но когда и тех и других достаточно много да и еще со сложными зависимостями, остается только ждать накладки.
AN>>Должен быть всегда один источник и смешанная работа просто не допускается. Или всегда абсолютно все свои текущие проекты как Длл-ки с сервера или все подключения через проекты (кроме чисто библиотечных, считаемых как бы не своими). То есть если есть иерархия проектов, то вся ветка либо/либо, но никак не комбинация в ветке.
A_A>Да. перемешивать нельзя — бардак будет еще тот.
А как тогда работать разработчику Длл-ки? Причем один разработчик часто отвечает за более чем одну Длл-ку?

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

A_A>А какая СКВ позволяет делать это автоматически?
Любая распределенная.

A_A>Я хочу сделать новую версию общей части для одного клиента:
В это время другой программист захотел сделать тоже самое.

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

A_A>В изначальном посте о необходимости версионирования исходников не было сказано,
A_A>поэтому вариант с подключением сорцов из транка как SVN:externals является нормальным.
Подключения без фиксирования ревизии не может быть нормальным.
Ибо ты потом не сможешь вытащить ту же версию исходников, с которой собирал.

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

A_A>>1) Если нет человека с такой должностью — нужно завести должность и взять человека
AN>А зачем, когда можно вполен обойтись без него просто использую другой подход.
Так в чем проблема? Используйте тот подход, который для Вас более выгоден.
A_A>>2) Совмещать кому-то из существующих
AN>Совмещать несколько празличных заданий особенно в стрессе релиза чревато.
+1

A_A>>Брать тогда, когда нужна новая функциональность.
A_A>>На каждую версию создавать ветки в СВН — если хочешь чтобы код соответствовал бинарникам(в моей практике это было не нужно).
AN>Уж сколько помню всегда с этим были проблемы.
+1

A_A>>Извини, но с таким подходом к разработке надо улучшать процессы разработки.
A_A>>Создается новая версия библиотеки -> она выкладывается куда-то в шару -> делается описание внесенных изменений -> идут уведомления клиентам о новой версии.
AN>Дело не идет о библиотеке и внешних клиентах, там все по другому. Разговор о команде разрабатывающей достаточно большой проект, скажем с полтинником подпроектов. И все проиходит именно на этапе разработки.

Вот именно в этом случае пригодится юзание библиотек.
Если был бы простенький проект на 2-3 человека с 10-15 проектами — тогда бы овчинка выделки не стоила и юзание сорцов по ссылке было удобнее.

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

AN>Значит голос за Длл-ки?
А как быть тогда с совмещением ссылок на Длл-ки и проекты?
Можно по-детальней?
Что делать разработчику именно этой Длл-ки в проекте?
тут есть два варианта:
1)Длл-ка принадлежит другой команде — вносится тикет на создание в ней фичи и ждем, когда эта команда нам выдаст новую длл-ку.
2)длл-ка наша — мы сами с ней делаем что хотим и не ждем никогда
И что делать остальным когда исходники уже в репозитории, но бильд длл-ок еще не готов. Ждать пока не будет все готово и после все брать?
Тут надо это дело автоматизировать, конечно.
Унас так:
1)коммитим исходники
2)берем номер нового билда
3)меняем на клиенте версию на новую
4)запускаем батник
И все.
А если в это же время закоммитились другие изменения, которые нужно пока избежать? (Допустим они исправили генерацию данных, и неправильные данные для теста уже получить просто невозможно)
Это сложный вопрос. Опять же:
1) Если длл-ка ваша — то вы всегда в курсе всех изменений
2) Тут надо отслеживать все изменения с текущей версии по ту, которую хотите заюзать.
То есть нужно отслеживать два источника: исходники и бинарники, и к тому же учитывать иерархию бинарников.
1) Если длл-ка ваша — вы следитие только за сорцами — на версии вам пофиг
2) Следите только за изменениями в функционале и версиями — на сорцы вам пофиг

С такими юз-кейсами ссылки на версионированные исходники, имхо, будут нести большой геморрой.

Тут на помощь конечно приходит CI, NuGet и хорошее покрытие тестами общего фцнкйионала.

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

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

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

A_A>>>>ИМХО, однозначно только использовать подключение библиотек.
A_A>>>>Назовем ради примера:
A_A>>>>общая часть — сервер,
A_A>>>>пользователи общей части — клиенты.
AN>>>То есть пример практически не связанного кода. Максимум — протоколы обмена, видимо.
A_A>>Отнюдь не только. Библиотеки .NET Framework — это связанный код с твоими проектами или нет?
AN>А у меня есть исходники .NET Framework в проекте?
Догадываюсь, что нету.
Так значит юзание библиотек является достаточным.

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

Q>>>>Можно пристально посмотреть в сторону svn:externals.
AN>>>Админ, блин подключил так дев ехпресс, так теперь в каждом проекте своя копия. Ужас просто.
A_A>>На сервере лежит только одна копия исходников, а на клиенте — да, на каждый svn:externals плюс одна локальная копия.
A_A>>Почему ужас-то? Места на диске не хватает?
AN>Допустим я обновляю версию бибилотеки, но вначале чисто для теста, как будет у меня работать. Теперь вместо одной замены нужно делать Х. Либо я могу для отладки просто сбилдить Длл-ки из исходников локально. Опять надо искать механизм подмены всех версий.
В случае ссылок на исходники количество телодвижений будет тоже.
А механизм подмены версий искать — да, надо — но это уже другая тема.
Q>>>>И вообще, повлиять на руководство в сторону приобщения к правильным и удобным инструментам.
AN>>>Для этого нужно полностью менять/перестраивать все сопутствующее окружение которое настраивалось и подключалось разными людьми в течении многих лет.
A_A>>Идешь к руководству с аргументами типа: после этих изменений мы будем меньше тратить времени на разработку -> и тут варианты:
A_A>>

время на разработку уменьшится — экономия бабла для заказчика
AN>ну это еще нужно доказать что время на разработку действительно Существенно уменьшится, в чем я несколько сомневаюсь.
A_A>>

заказчик будет получать продукты быстрее — сможет выходить на рынок с новым продуктом раньше — получение новых прибылей для заказчика
A_A>>

система будет более стабильна(будет меньше возможных багов) — вероятность потери клиентов для заказчика снизится — заказчик будет меньше терять бабла
AN>Как система контроля версий влияет на количество багов?
Я говорю не за СКВ, а за исключение потенциальной возможности изменений исходников людьми, которые не должны этого делать в данный момент.

A_A>>С такими аргументами нормальное руководство утверждает.
AN>А кто, сколько времени и на что будет перестраивать все остальное?
делаете предварительные исследования в свободное от работы время(это на самом деле вам же, разработчикам, нужно )
закидываете ссылками, что это можно сделать
берете время
делаете

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

Q>>>>Когда угодно. У тебя стоит ссылка на пакет версии 3.4.0.128. То, что на билд-сервере появляются версии 3.4.0.129, 3.4.0.130, etc твою программу не ломает. То же, что и со сторонними библиотеками. Скажем, используешь ты NUnit 2.5.9.10348. То, что вышла новая версия NUnit 2.5.10.11092 никоим образом на твою программу повлиять не может, пока ты сам не решишь обновиться.
AN>>>Во внутренности NUnit мне не нужно лезть. Допустим получил я от библииотеке 0, а должно быть 5. Лезешь с отладкой и видишь что 0 ну никак не может получится. А это просто версии исходников и либы не совпадают.
A_A>>Нужно собирать либу с такой версией, чтобы можно было найти реальные исходники.
AN>Кто и как будет проверять версию Длл-ки при входе в функцию?
Тут поможет перегрузка функций, если уж совсем никак.

AN>>>>>А будет ли обеспечено, что исходники всех разработчиков будут точно сообтветствовать бинарникам.

Q>>>>Не понял вопрос. Твоя переиспользуемая библиотека теперь выглядит так же, как не твоя переиспользуемая библиотека. От которой у тебя нет, и не нужны исходники. Все проекты всегда ссылаются на точную версию строгоименованной библиотеки.
AN>>>Кажется, я уловил проблему. Все будет работать когда ВСЕ проекты подключены как Длл-ки (исключая вариант с отладкой кода). Но если я разработчик и мне нужно иметь актуальную версию Длл-ки, то их получается уже две версии. Одна собранная по исходникам, другая из репозитория. Дя какого-то небольшого количества еще можно все отследить, но когда и тех и других достаточно много да и еще со сложными зависимостями, остается только ждать накладки.
AN>>>Должен быть всегда один источник и смешанная работа просто не допускается. Или всегда абсолютно все свои текущие проекты как Длл-ки с сервера или все подключения через проекты (кроме чисто библиотечных, считаемых как бы не своими). То есть если есть иерархия проектов, то вся ветка либо/либо, но никак не комбинация в ветке.
A_A>>Да. перемешивать нельзя — бардак будет еще тот.
AN>А как тогда работать разработчику Длл-ки? Причем один разработчик часто отвечает за более чем одну Длл-ку?
А в чем проблема-то?
Просто надо больше комунницировать, чтобы о таких изменениях все были в курсе.
Почитайте про scrum.

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

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

A_A>>А какая СКВ позволяет делать это автоматически?
WH>Любая распределенная.
давайте уточним, что мы имеем ввиду одно и тоже.

Имеем:
1)Общий функционал, который лежит в своем репозитории.
2)Куча проектов, раскиданных по разным репозиториям, которые будут юзать этот общий проект(как физическую ссылку в VS)
и эти все проекты будут версионироваться.

Нужно:
1)Сделать версионирование общего функционала
2)Иметь возможность быстрого переключения версий общего функционала
3)Запретить некоторым юзерам менять общий функционал

Как распределенная скв будет делать это автоматически?

A_A>>Я хочу сделать новую версию общей части для одного клиента:
WH>В это время другой программист захотел сделать тоже самое.
WH>
В обоих случаях топикстартера это возможно.

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

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

A_A>>В изначальном посте о необходимости версионирования исходников не было сказано,
A_A>>поэтому вариант с подключением сорцов из транка как SVN:externals является нормальным.
WH>Подключения без фиксирования ревизии не может быть нормальным.
WH>Ибо ты потом не сможешь вытащить ту же версию исходников, с которой собирал.
дык, я солидарен, что если требуется версионирование общей части, то подключение исходников как
SVN:externals несет в себе больше возможных неприятностей, чем юзание библиотек

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

A_A>>Если на любые изменения в сервере делать ветки в СКВ

Да не надо никакие ветки вручную делать, предполагалось просто, что у разных людей ссылки на ревизии разной степени свежести.

A_A>>и менять ссылки у клиентов на новый урл, то да — в данной ситуации различий нет. :beer:

Пошла какая-то мешанина из сборки сервера и деплоймента сервера в продакшн. Или я чего-то не понял? Давай рассмотрим пример проще, не клиент-сервер, а БиблиотекаПримитивов и ВысокоуровневаяОбёртка. Чтоб без урлов.

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

Нет. Есть конфигурация для клиента и сервера.

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

Q>>У тебя есть ссылка на dll'ку, методы в которой хочешь пройти пошагово. Но у тебя нет PDB. Значит его нужно отдельно собрать из исходников. Т.е. опять же решить проблему, какая версия исходников соответствовала той версии dll'ки, на которую у тебя ссылка.

A_A>Поставлять PDB вместе с DLL.
A_A>Мы так и делаем — в NuGet пакете PDB вместе с DLL.

Откровенно говоря, я не знаю деталей внутреннего устройства PDB и тонкостей их распространения вместе в библиотеками. Но во всех (немногочисленных, но без исключения) NuGet-пакетах, которые таки содержали PDB-файлы, при открытии последних видны строки типа «C:\Users\VasyaPupkin\SomeProject\SomeModule\SomeClass.cs». Простите мне моё невежество, но, емнип, я никогда не использовал чужие pdb. Скажите, они вообще работают? И если да, то как? Я так понимаю, они нужны для связи символов с исходниками. И судя по тому, что я вижу внутри pdb-файла, они связывают символы с исходниками разработчика, а не моим комплектом исходников.

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

A_A>1)Сделать версионирование общего функционала
А версионник у нас чем занимается?

A_A>2)Иметь возможность быстрого переключения версий общего функционала
А версионник нам на что? Они прекрасно справляются с вытаскиванием другой равизии.

A_A>3)Запретить некоторым юзерам менять общий функционал
Зачем запретить?

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

AN>PDB то будет идти с Длл-кой, но вот гарантировать совместимость исходников с ними, да проблема.
AN>И кстати, как сгенерить PDB без DLL-ки?

http://www.rsdn.ru/forum/philosophy/4503615.aspx

Автор: Qbit86
Дата: 19.11.11

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

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

A_A>>>Если на любые изменения в сервере делать ветки в СКВ

Q>Да не надо никакие ветки вручную делать, предполагалось просто, что у разных людей ссылки на ревизии разной степени свежести.

A_A>>>и менять ссылки у клиентов на новый урл, то да — в данной ситуации различий нет.

Q>Пошла какая-то мешанина из сборки сервера и деплоймента сервера в продакшн. Или я чего-то не понял? Давай рассмотрим пример проще, не клиент-сервер, а БиблиотекаПримитивов и ВысокоуровневаяОбёртка. Чтоб без урлов.

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

Q>Нет. Есть конфигурация для клиента и сервера.

Тогда разницы нет, за исключением случая, что девелопер ВысокоуровневойОбёртки может внести изменения и закоммитить код БиблиотекиПримитивов.

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

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

Q>>>У тебя есть ссылка на dll'ку, методы в которой хочешь пройти пошагово. Но у тебя нет PDB. Значит его нужно отдельно собрать из исходников. Т.е. опять же решить проблему, какая версия исходников соответствовала той версии dll'ки, на которую у тебя ссылка.

A_A>>Поставлять PDB вместе с DLL.
A_A>>Мы так и делаем — в NuGet пакете PDB вместе с DLL.

Q>Откровенно говоря, я не знаю деталей внутреннего устройства PDB и тонкостей их распространения вместе в библиотеками. Но во всех (немногочисленных, но без исключения) NuGet-пакетах, которые таки содержали PDB-файлы, при открытии последних видны строки типа «C:\Users\VasyaPupkin\SomeProject\SomeModule\SomeClass.cs». Простите мне моё невежество, но, емнип, я никогда не использовал чужие pdb. Скажите, они вообще работают? И если да, то как? Я так понимаю, они нужны для связи символов с исходниками. И судя по тому, что я вижу внутри pdb-файла, они связывают символы с исходниками разработчика, а не моим комплектом исходников.

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

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

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

A_A>Тогда разницы нет, за исключением случая, что девелопер ВысокоуровневойОбёртки может внести изменения и закоммитить код БиблиотекиПримитивов.

Ещё может легко и непринуждённо по ней отлаживаться. Найти какой-нибудь мелкий баг, не отходя от кассы его исправить.

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

A_A>>3)Запретить некоторым юзерам менять общий функционал
WH>Зачем запретить?
потому что они джуниоры и не имеют еще достаточной квалификации, чтобы менять критически важную для проекта часть

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

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

A_A>>Тогда разницы нет, за исключением случая, что девелопер ВысокоуровневойОбёртки может внести изменения и закоммитить код БиблиотекиПримитивов.

Q>Ещё может легко и непринуждённо по ней отлаживаться. Найти какой-нибудь мелкий баг, не отходя от кассы его исправить.

тут я не спорю, этот минус я изначально указал

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

A_A>pdb дает нам возможность узнать номера строк в файлах при исключениях

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

A_A>pdb дает нам возможность узнать номера строк в файлах при исключениях

Мне важнее уметь зайти в код вызываемой функции. Т.е. чтоб отладчик с помощью этого *.pdb умел связывать *.dll и *.cs. Насколько я понимаю, это достигается тем, что в pdb вшивается информация об окружении конкретного разработчика (в частности пути к исходникам, которые среда должна открыть в процессе отладки), который сгенерировал этот pdb-файл.

A_A>версию исходников мы узнаем из версии пакета

Версия пакета покажет только номер ревизии, которая уникальная только в рамках одного клона репозитория (в случае распределённых VCS). Уникальный по всем репозиториям changeset id представляет из себя 40-символьный хэш, его так просто в версию пакета не запихнёшь, нужна заморачиваться с кастомным атрибутом, например. Потом лезть в манифест dll-ки, чтоб его узнать.

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

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

A_A>тут я не спорю, этот минус я изначально указал

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

Ссылки на бинарники могут пригодиться в таком сценарии. Есть БиблиотекиПримитивов общего назначения, которая может выступать самостоятельным продуктом, безотносительно контекста; т.е. не заточена под какой-то конкретный проект. Её поставляем без исходников.

Кроме того, нужно написать ПользовательскоеПриложение, которое использует всю мощь и величие нашей БиблиотекиПримитивов, причём заказчику предоставляется исходный код этого ПользовательскогоПриложения в качестве демонстрации использования API нашей БиблиотекиПримитивов.

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

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

A_A>>pdb дает нам возможность узнать номера строк в файлах при исключениях

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

A_A>>pdb дает нам возможность узнать номера строк в файлах при исключениях

Q>Мне важнее уметь зайти в код вызываемой функции. Т.е. чтоб отладчик с помощью этого *.pdb умел связывать *.dll и *.cs. Насколько я понимаю, это достигается тем, что в pdb вшивается информация об окружении конкретного разработчика (в частности пути к исходникам, которые среда должна открыть в процессе отладки), который сгенерировал этот pdb-файл.
Да, и еще он как-то знает версию .cs файла(я думаю в него зашит хеш-код исходника).
И если ему попытаться подсунуть измененный исходник, то ничего не выйдет.

A_A>>версию исходников мы узнаем из версии пакета

Q>Версия пакета покажет только номер ревизии, которая уникальная только в рамках одного клона репозитория (в случае распределённых VCS). Уникальный по всем репозиториям changeset id представляет из себя 40-символьный хэш, его так просто в версию пакета не запихнёшь, нужна заморачиваться с кастомным атрибутом, например. Потом лезть в манифест dll-ки, чтоб его узнать.

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

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

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

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

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

A_A>>тут я не спорю, этот минус я изначально указал

Q>Но и я в свою очередь не отвергаю категорически идею ссылок на бинарники. Просто предлагаю вариант с пакетами NuGet вместо каких-то расшаренных папок, куда непонятно кто кладёт обновляющиеся версии библиотек, и все остальные должны при желании обновиться лезть менять ссылки на строгоименованные сборки.
+1

Q>Ссылки на бинарники могут пригодиться в таком сценарии. Есть БиблиотекиПримитивов общего назначения, которая может выступать самостоятельным продуктом, безотносительно контекста; т.е. не заточена под какой-то конкретный проект. Её поставляем без исходников.
так если БиблиотекаПримитивов будет заточена под какой-то конкретный проект — нет смысла вообще отделять ее от этого проекта
но, насколько я понял, у топикстартера эта БиблиотекаПримитивов юзается в разных проектах

Q>Кроме того, нужно написать ПользовательскоеПриложение, которое использует всю мощь и величие нашей БиблиотекиПримитивов, причём заказчику предоставляется исходный код этого ПользовательскогоПриложения в качестве демонстрации использования API нашей БиблиотекиПримитивов.
имхо, заказчику вообще пофиг как мы там внутри юзаем — со ссылками на исходники или библиотеки
ему важно, чтобы функционал был готов в нужный для него срок
вот тут и нужно разработчикам решать как организовать такие сценарии

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

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

A_A>>потому что они джуниоры и не имеют еще достаточной квалификации, чтобы менять критически важную для проекта часть
WH>Ты с распределенными версионниками вообще работал?
Вообще-то нет
WH>Они для того и созданы чтобы изменения без изучения ответственными лицами не проходили в основной репозиторий.
Процесс коде-ревью встроенный в СКВ?
Прикольно.
Тогда распределенные СКВ рулят.

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

Q>>Кроме того, нужно написать ПользовательскоеПриложение, которое использует всю мощь и величие нашей БиблиотекиПримитивов, причём заказчику предоставляется исходный код этого ПользовательскогоПриложения в качестве демонстрации использования API нашей БиблиотекиПримитивов.

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

Нет. Заказчику нужны библиотеки (исходники которых мы отдавать не хотим), которые он (силами своих программистов) будет использовать в своих проектах. Плюс ему нужен ДемонстрационныйПроект (разумеется, с исходниками, которые при этом собираются), чтоб можно было использовать нашу БиблиотекуПримитивов, глядя на то, как она используется в ДемонстрационномПроекте.

Если мы предоставим ему ДемонстрационныйПроект, который ссылается на проекты БиблиотекиПримитивов, и при этом выдерем исходники БиблиотекиПримитивов, то у него ничего не соберётся.

Т.е. мы, разрабатывая ДемонстрационныйПроект входим в роль заказчика и пользуемся только теми средствами, которые будут ему доступны. Ему не будет доступна опция «сослаться на проект» — у него не будет проекта, только бинарник.

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

Z>>Зато факт, что используемый реально код не соответствует исходникам вызывает бешенную ненависть после кучи времени потраченного на детект ситауции.
AN>На это отвечают — прищучим всех Во что слабо верится.

Щучить придётся постоянно, щукари, блин.

Z>>А оно вам надо? И зачем вообще тратить время на загрузки "актуальных версий"?
AN>Аргументируют, что Длл-ку имеет право изменить только "автор". А при наличии исходников, кто угодно. В результате локальная версия может не совпадать с конечной.

Странная аргументация, очень странная. Она допустима только при одном условии: если автор работает в другой компании. Если все "авторы" работают в одной конторе — исходники должны быть доступны всем.

AN>Хотя если все билдится из репозитория, то это уже относительно простая проблема разработчика не иметь изменений в "чужих" проектах. При чекине видно на раз.

Вот именно.

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

Q>Нет. Заказчику нужны библиотеки (исходники которых мы отдавать не хотим), которые он (силами своих программистов) будет использовать в своих проектах. Плюс ему нужен ДемонстрационныйПроект (разумеется, с исходниками, которые при этом собираются), чтоб можно было использовать нашу БиблиотекуПримитивов, глядя на то, как она используется в ДемонстрационномПроекте.

Q>Если мы предоставим ему ДемонстрационныйПроект, который ссылается на проекты БиблиотекиПримитивов, и при этом выдерем исходники БиблиотекиПримитивов, то у него ничего не соберётся.

Q>Т.е. мы, разрабатывая ДемонстрационныйПроект входим в роль заказчика и пользуемся только теми средствами, которые будут ему доступны. Ему не будет доступна опция «сослаться на проект» — у него не будет проекта, только бинарник.

Да, поддерживаю.

Еще плюс бинарников в том, что у нас в солюшене будет на один проект меньше

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

Сначала ответ — лучше исходники, так как это позволяет легче понимать код (навигация при просмотре по зависимостям не обрывается на бинарниках). Единственный момент, который стоит помнить — это влияет на производительность студии. Но если проект суммарно не очень большой, или если машина на современном уровне, то замедление обычно некритично.

AN>Хотя некоторые имеют мнение, что при наличии решарпера и многих разработчиков лучше пользовать исключительно ДЛЛ-ки

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

AN>А то что кто то забудет актуальную версию загрузить, нужно регулировать постановлениями партии и правительства

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

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

Z>>>А оно вам надо? И зачем вообще тратить время на загрузки "актуальных версий"?
AN>>Аргументируют, что Длл-ку имеет право изменить только "автор". А при наличии исходников, кто угодно. В результате локальная версия может не совпадать с конечной.

ГВ>Странная аргументация, очень странная. Она допустима только при одном условии: если автор работает в другой компании. Если все "авторы" работают в одной конторе — исходники должны быть доступны всем.

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

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

A_A>Процесс коде-ревью встроенный в СКВ?
A_A>Прикольно.
A_A>Тогда распределенные СКВ рулят.
Он не то чтобы встроен, просто распределенные СКВ очень хорошо к этому приспособлены.

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

ГВ>>Странная аргументация, очень странная. Она допустима только при одном условии: если автор работает в другой компании. Если все "авторы" работают в одной конторе — исходники должны быть доступны всем.

A_A>А если разработчики работают в одной компании, но в разных командах(допустим даже под одним проджект менеджером).

Никакой разницы.

A_A>И тут разработчик вносит изменения в общий код, который принадлежит другой команде(которая уже выделила свою архитектуру этого проекта)

Вообще говоря, про такие изменения лучше ставить в известность ту самую "другую" команду. Или отправлять ей соответствующую заявку.

A_A>и эти изменения не вписываются аж никак в ихнюю архитектуру.

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

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

Ой, какие мы нежные.

Ты не путай: "могут вносить" и "будут вносить". Одно из другого, в общем, не следует. Это прямая задача управленцев — объяснить, что в чужие исходники лазить не надо. Смотреть можно, менять — нет. Зато такой подход снимает кучу проблем по части выяснения источника ошибок.

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

ГВ>Ты не путай: "могут вносить" и "будут вносить". Одно из другого, в общем, не следует. Это прямая задача управленцев — объяснить, что в чужие исходники лазить не надо. Смотреть можно, менять — нет. Зато такой подход снимает кучу проблем по части выяснения источника ошибок.

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

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

Вероятность такая отсутствует в случае ссылок на бинарники.

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

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

Задача-максимум: иметь возможность полностью пересобрать все проекты на любой машине разработчика. Но много зависит от размера исходников. Если у вас их сотни мегабайт с полусуточным циклом компиляции, то, пожалуй, полный доступ нужен только для справочных целей, а для работы достаточно периодически обновляемых бинарников. А если сборка всех ваших исходников укладывается в час-два (сторонние библиотеки сейчас не считаем), то уместно иметь полную копию всех исходных текстов.

А всякие параноидальные "защиты" — это всё детсад, напакостить при желании можно где угодно. Скажем, кто-то даст кому-то по дружбе доступ к репозиторию... Короче, всё это разговоры в пользу бедных — организационные задачи техничесиким средствами не решаются.

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

A_A>Тут мы на ровном месте получаем конфликт, которого можем избежать если изменения будут вносить только авторы системы

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

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

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

A_A>>Процесс коде-ревью встроенный в СКВ?
A_A>>Прикольно.
A_A>>Тогда распределенные СКВ рулят.
WH>Он не то чтобы встроен, просто распределенные СКВ очень хорошо к этому приспособлены.

А кстати, если у SVN репзитория менять svn:externals, то хранится ли в истории эта информация?

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

ГВ>>Ты не путай: "могут вносить" и "будут вносить". Одно из другого, в общем, не следует. Это прямая задача управленцев — объяснить, что в чужие исходники лазить не надо. Смотреть можно, менять — нет. Зато такой подход снимает кучу проблем по части выяснения источника ошибок.

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

Не верю. Точка. У тебя есть задача и есть ограниченная область, в рамках которой ты можешь её решать.

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

Нет, так нельзя делать. То есть временно что-то менять — нет проблем, только перед окончательной сборкой изменения надо откатывать и т.п. Если ты нашёл ошибку не в своём коде, обратись к владельцу и далее по всему циклу.

A_A>Потом делаешь коммит на папочке проекта и случайно коммитишь изменения в чужой код.
A_A>Смотришь на билд-сервер -> все "свои" проекты успешно сбилдились и идешь пить пиво.

Значит, надо следить за тем, что ты делаешь, а не "жмакать кнопочку и идти пить пиво". Ты не один в конце концов.

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

Есть вариант: можно ставить в проектах ссылки на бинарники, но при этом ещё и выкачивать полные исходники, чтобы эти бинарники можно было пересобрать. Тогда ты сможешь сделать так:

— Скачать все нужные исходники в одном солюшене;
— Собрать все нужные бинари;
— Отделить нужные тебе проекты в обособленный солюшен — и всё, ничего ты случайно не поменяешь.

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

A_A>>Потом делаешь коммит на папочке проекта и случайно коммитишь изменения в чужой код.
A_A>>Смотришь на билд-сервер -> все "свои" проекты успешно сбилдились и идешь пить пиво.

ГВ>Значит, надо следить за тем, что ты делаешь, а не "жмакать кнопочку и идти пить пиво". Ты не один в конце концов.

Пример:
Пришел новый человек в комманду, предпочитающий разбираться во всем самостоятельно и лишний раз никого "глупыми" вопросами не отвлекать.
Ему повесили таску пофиксить багу в функионале, который юзает чужой код.
И тим-лид забыл ему сказать, что тот код трогать низзя.

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

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

Вероятность то есть.

ГВ>Есть вариант: можно ставить в проектах ссылки на бинарники, но при этом ещё и выкачивать полные исходники, чтобы эти бинарники можно было пересобрать. Тогда ты сможешь сделать так:

ГВ>- Скачать все нужные исходники в одном солюшене;
ГВ>- Собрать все нужные бинари;
ГВ>- Отделить нужные тебе проекты в обособленный солюшен — и всё, ничего ты случайно не поменяешь.

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

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

ГВ>А всякие параноидальные "защиты" — это всё детсад, напакостить при желании можно где угодно. Скажем, кто-то даст кому-то по дружбе доступ к репозиторию...

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

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

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

A_A>>Тут мы на ровном месте получаем конфликт, которого можем избежать если изменения будут вносить только авторы системы

Q>Если изменение должны вносить только авторы системы, то у посторонних должны быть права максимум на чтение.

Да, согласен.

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

A_A>А кстати, если у SVN репзитория менять svn:externals, то хранится ли в истории эта информация?

Естественно.

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

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

A_A>>А кстати, если у SVN репзитория менять svn:externals, то хранится ли в истории эта информация?

H>Естественно.

Так тогда чем распределенные СКВ в данном случае лучше серверных?

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

WH>>Ибо когда правишь код во внешнем модуле, сразу же должен создаваться новый бранч для этого кода.
A_A>А какая СКВ позволяет делать это автоматически?

ClearCase хорошо с бранчами умеет работать. Например, позволяет собрать бранч из отдельных файлов любых веток и версий. Она вообще много чего позволяет. Но денег стоит ($4600/user).

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

ГВ>А всякие параноидальные "защиты" — это всё детсад, напакостить при желании можно где угодно. Скажем, кто-то даст кому-то по дружбе доступ к репозиторию... ГВ>Короче, всё это разговоры в пользу бедных — организационные задачи техничесиким средствами не решаются.

Кстати вот на перекрестках есть светофоры — они предназначены разруливать организационную задачу — ПДД
Что происходит если эта организационная задача(в нашем случае возможность изменения чужого кода) будет нарушена:
1) Возможны жертвы участников(в нашем случае девелоперы)
2) Вызывается гаишник в качестве судьи (в нашем случае проджект менеджер)
3) Выносится наказание(в итоге у кого-то будут неприятности)

В итоге в развитых странах начали переходить на путепроводы везде где возможно.
И теперь наша организационная задача не может быть нарушена в принципе.(И никто в компании не имеет проблем в принципе).

Является ли эта защита параноидальной?

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

A_A>Пример:
A_A>Пришел новый человек в комманду, предпочитающий разбираться во всем самостоятельно и лишний раз никого "глупыми" вопросами не отвлекать.

Ну и что? Почти все такие.

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

По ушам тимлиду. Сходу и без разговоров. Что значит, "забыл сказать"? А для пописать он в уборную не забыл сходить?

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

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

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

Зато в следующий раз таких неприятностей не будет. А мелкие технические недоразумения — чепуха.

ГВ>>Есть вариант: можно ставить в проектах ссылки на бинарники, но при этом ещё и выкачивать полные исходники, чтобы эти бинарники можно было пересобрать. Тогда ты сможешь сделать так:

ГВ>>- Скачать все нужные исходники в одном солюшене;
ГВ>>- Собрать все нужные бинари;
ГВ>>- Отделить нужные тебе проекты в обособленный солюшен — и всё, ничего ты случайно не поменяешь.

A_A>а как будем качать исходники различных версий?
A_A>паковать в пакет с бинарями?

Ответ зависит от того, как выглядит ваше дерево (деревья) проектов. В принципе, это решается скриптами и бранчами.

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

ГВ>>А всякие параноидальные "защиты" — это всё детсад, напакостить при желании можно где угодно. Скажем, кто-то даст кому-то по дружбе доступ к репозиторию...

A_A>кстати в логах то будет аккаунт именно того кто даст доступ по дружбе,
A_A>так что тут уж дружба-дружбой а аккаунты врознь

Ага-ага.

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

H>>Естественно.

A_A>Так тогда чем распределенные СКВ в данном случае лучше серверных?

Тем что они распределенные. В git-е кроме submodule (аналог svn:externals) есть subtree.

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

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

A_A>>Пример:
A_A>>Пришел новый человек в комманду, предпочитающий разбираться во всем самостоятельно и лишний раз никого "глупыми" вопросами не отвлекать.

ГВ>Ну и что? Почти все такие.

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

ГВ>По ушам тимлиду. Сходу и без разговоров. Что значит, "забыл сказать"? А для пописать он в уборную не забыл сходить?

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

ГВ>Если тимлид такой дурак, что "забывает" сказать про важнейший момент — нах такого тимлида. Это какая-то шиза, право слово.

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

ГВ>Зато в следующий раз таких неприятностей не будет. А мелкие технические недоразумения — чепуха.

По ушам то надавать дело всегда нехитрое.

А в случае с бинарями новичок придет к лиду, что бага в такой-то библиотеке и чего дальше делать-то мол.
И вопрос будет решаться теми, кто несет ответственность за эти модули со 100-процентной вероятностью.

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

ГВ>>А всякие параноидальные "защиты" — это всё детсад, напакостить при желании можно где угодно. Скажем, кто-то даст кому-то по дружбе доступ к репозиторию... ГВ>Короче, всё это разговоры в пользу бедных — организационные задачи техничесиким средствами не решаются.
A_A>Кстати вот на перекрестках есть светофоры — они предназначены разруливать организационную задачу — ПДД

Ну началось... Светофоры решают задачу "подать сигнал водителям", чем способствуют решению задачи управления трафиком. А ПДД регламентируют поведение водителей при получении того или иного сигнала (ГИБДД контролирует). Сам по себе светофор без ПДД и ГИБДД — никому не нужная мигалка.

A_A>Что происходит если эта организационная задача(в нашем случае возможность изменения чужого кода) будет нарушена:

Будут нарушены ПДД, а не организационная задача.

A_A>[...]
A_A>Является ли эта защита параноидальной?

Плохая аналогия.

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

A_A>А в случае с бинарями новичок придет к лиду, что бага в такой-то библиотеке и чего дальше делать-то мол.

А как он узнает, что бага в такой-то библиотеке а не в его коде?

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

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

H>>>Естественно.

A_A>>Так тогда чем распределенные СКВ в данном случае лучше серверных?

H>Тем что они распределенные. В git-е кроме submodule (аналог svn:externals) есть subtree.

не понимаю профита.

Пример из SVN:
1)Есть общий функционал в транке
2)Клиенты юзают различные номера ревизий этого функционала

со все этим SVN справляется, в чем геморрой-то будет?

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

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

ГВ>>>А всякие параноидальные "защиты" — это всё детсад, напакостить при желании можно где угодно. Скажем, кто-то даст кому-то по дружбе доступ к репозиторию... ГВ>Короче, всё это разговоры в пользу бедных — организационные задачи техничесиким средствами не решаются.
A_A>>Кстати вот на перекрестках есть светофоры — они предназначены разруливать организационную задачу — ПДД

ГВ>Ну началось... Светофоры решают задачу "подать сигнал водителям", чем способствуют решению задачи управления трафиком. А ПДД регламентируют поведение водителей при получении того или иного сигнала (ГИБДД контролирует). Сам по себе светофор без ПДД и ГИБДД — никому не нужная мигалка.

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

A_A>>Что происходит если эта организационная задача(в нашем случае возможность изменения чужого кода) будет нарушена:

ГВ>Будут нарушены ПДД, а не организационная задача.

A_A>>[...]
A_A>>Является ли эта защита параноидальной?

ГВ>Плохая аналогия.

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

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

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

A_A>>А в случае с бинарями новичок придет к лиду, что бага в такой-то библиотеке и чего дальше делать-то мол.

ГВ>А как он узнает, что бага в такой-то библиотеке а не в его коде?

К примеру при вызове метода поймает NotImplementedException

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

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

A_A>>ИМХО, однозначно только использовать подключение библиотек.
WH>хъ
WH>Это все прекрасно делается с нормальными системами контроля версий

Автор: Qbit86
Дата: 19.11.11

.
WH>Поставь git или hg и будет тебе счастье.

Ведь то же самое можно сделать и на SVN.
Чем распределенные СКВ в данном случае лучше?

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

ГВ>>Ну началось... Светофоры решают задачу "подать сигнал водителям", чем способствуют решению задачи управления трафиком. А ПДД регламентируют поведение водителей при получении того или иного сигнала (ГИБДД контролирует). Сам по себе светофор без ПДД и ГИБДД — никому не нужная мигалка.

A_A>Организационная задача — сделать дорожное движение безопасным.

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

A_A>Организационный инструмент решения этой задачи — Правила дорожного движения.

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

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

A_A>Технический инструмент решения этой задачи — путепровод.

Ну тоже, в общем, верно, но это инструмент решения очень узкой и частной задачи — развязать трафик в определённом узле, а всех остальных задач он не снимает. По-прежнему кто-то должен рассказать о том, как надо понимать разметку, что означают дорожные знаки, как нумеруются полосы, как правильно перестраиваться и т.п. То есть весь цикл обучения ПДД от этого никуда не девается. А решение строить путепровод принимается после обсчётов экономической пользы от такой стройки: каждый перекрёсток развязкой не заменишь.

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

ГВ>>Плохая аналогия.
A_A>имхо, аналогия очевидна — избавляемся от рисков получения потенциальных проблем в редких случаях

Разве что очень поверхностная. На самом деле тут вопрос в цене. ИМХО, всяко проще объяснить людям, что не надо лазить в чужой код (читай, рассказать о правилах перестроения), чем выдумывать сложные инструментальные подходы (читай, строить отдельный путепровод для каждого маршрута из всех точек А во все точки Б).

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

ГВ>>А как он узнает, что бага в такой-то библиотеке а не в его коде?
A_A>К примеру при вызове метода поймает NotImplementedException

А как он будет такую проблему решать? Неужели кинется дописывать код?

ч
AN>Для MSVC, под виндами, С#, winforms, если что.
AN>Временами на работе возникают дискуссии, что подключать лучше в солюшин как внешние ссылки при наличии исходников — DLL-ки или проекты.
AN>Понятно что абсолютно однозначного ответа нет, зависит от конкретной ситуации. Допустим, когда исходники стабильные и практически не меняются, либо от кого-то другого, то видимо DLL-ки с PDB (и отдельными исходниками для отладки) лучше. По крайней мере, нет никакой возможности изменить непреднамеренно код.

AN>Речь же идет исключительно об исходниках текущего проекта, собираемого из многих подпроектов. Просто часто сталкивался, когда исходники чуть чуть отличаются от ДЛЛ-ки и фиг поймешь отчего вдруг не работает/вылетает. Хотя некоторые имеют мнение, что при наличии решарпера и многих разработчиков лучше пользовать исключительно ДЛЛ-ки, несмотря на наличие в солюшин всех требуемы подпроектов с исходниками. А то что кто то забудет актуальную версию загрузить, нужно регулировать постановлениями партии и правительства
AN>Хотелось бы услышать различные мнения за и против каждого из подходов, чтобы не ругатся до состояния "пены у рта".

В каждом случае по разному

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

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

A_A>>>1) Если нет человека с такой должностью — нужно завести должность и взять человека
AN>>А зачем, когда можно вполен обойтись без него просто использую другой подход.
A_A>Так в чем проблема? Используйте тот подход, который для Вас более выгоден.
Хотелось бв иметь какие то критерии для выборато гото или иного подхода.
Получается тогда для подхода с Длл-ками желателен отдельный человек.

A_A>>>Извини, но с таким подходом к разработке надо улучшать процессы разработки.
A_A>>>Создается новая версия библиотеки -> она выкладывается куда-то в шару -> делается описание внесенных изменений -> идут уведомления клиентам о новой версии.
AN>>Дело не идет о библиотеке и внешних клиентах, там все по другому. Разговор о команде разрабатывающей достаточно большой проект, скажем с полтинником подпроектов. И все проиходит именно на этапе разработки.

A_A>Вот именно в этом случае пригодится юзание библиотек.
A_A>Если был бы простенький проект на 2-3 человека с 10-15 проектами — тогда бы овчинка выделки не стоила и юзание сорцов по ссылке было удобнее.
Честно говоря, не вижу зависимости удобства от количества, если не учитывать какие то определенные параметры, например время компиляции (в данном случаем им можно пренебречь). То бишь нужно определится с критериями.

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

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

AN>>Значит голос за Длл-ки?
A_A>А как быть тогда с совмещением ссылок на Длл-ки и проекты?
A_A>Можно по-детальней?
Допустим есть решение использовать подключение через Длл-ки, тогда абсолютно все проекты обязаны подключаться как Длл-ки, а Длл-ки браться из одного места. Что тогда делать разработчику Длл-ки?
Ведь ему вначале нужно иметь локальную копии для проверки/тестирования, а наличие копии входит в противоречие с требованием "одного источника". Точнее, это требование является необходимым для "внутренностей" ветки иерархии проектов/Длл-ок. Окончания веток- листики этому требования не подчиняются. Их можно включать как нужно в данной ситуациии.
A_A>Что делать разработчику именно этой Длл-ки в проекте?
A_A>тут есть два варианта:
A_A>1)Длл-ка принадлежит другой команде — вносится тикет на создание в ней фичи и ждем, когда эта команда нам выдаст новую длл-ку.
Тут видимо подразумевается, что проект принадлежит конечному листу иерархии проектов.
A_A>2)длл-ка наша — мы сами с ней делаем что хотим и не ждем никогда
Вот именно ждать и нужно. "Владелец" Длл-ки нужен вначале найти и исправить проблему, а остальные ждут пока будет готова очереная порция Длл-ок. Хотя можно сказать, берите файл х проекта У. К тому-же разработчик при создании локальной Длл-ки, должне пользоваться "другим источником" — исходниками. А при использовании второго источника должна быть гарантия, что эти два истоника синхронизированы. К тому нужно иметь и локалный механизм "подмены" Длл-ок.
A_A>И что делать остальным когда исходники уже в репозитории, но бильд длл-ок еще не готов. Ждать пока не будет все готово и после все брать?
A_A>Тут надо это дело автоматизировать, конечно.
A_A>Унас так:
A_A>1)коммитим исходники
A_A>2)берем номер нового билда
A_A>3)меняем на клиенте версию на новую
A_A>4)запускаем батник
A_A>И все.
A_A>А если в это же время закоммитились другие изменения, которые нужно пока избежать? (Допустим они исправили генерацию данных, и неправильные данные для теста уже получить просто невозможно)
A_A>Это сложный вопрос. Опять же:
A_A>1) Если длл-ка ваша — то вы всегда в курсе всех изменений
Даже если и в курсе, нужно отслеживать и исходники и бинарники (в случае подключения Длл-ок), да и еще желательно знать зависимости бинарников.
A_A>2) Тут надо отслеживать все изменения с текущей версии по ту, которую хотите заюзать.
A_A>То есть нужно отслеживать два источника: исходники и бинарники, и к тому же учитывать иерархию бинарников.
A_A>1) Если длл-ка ваша — вы следитие только за сорцами — на версии вам пофиг
Пофиг не могут быть, ведь подключаются только Длл-ки. (Не говорим о "конечных листиках")
A_A>2) Следите только за изменениями в функционале и версиями — на сорцы вам пофиг
на сорцвы не пофиг, откуда бильдить локальные версии на время правки?

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

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

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

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

A_A>>>>>ИМХО, однозначно только использовать подключение библиотек.
A_A>>>>>Назовем ради примера:
A_A>>>>>общая часть — сервер,
A_A>>>>>пользователи общей части — клиенты.
AN>>>>То есть пример практически не связанного кода. Максимум — протоколы обмена, видимо.
A_A>>>Отнюдь не только. Библиотеки .NET Framework — это связанный код с твоими проектами или нет?
AN>>А у меня есть исходники .NET Framework в проекте?
A_A>Догадываюсь, что нету.
A_A>Так значит юзание библиотек является достаточным.
Это для случая когда библиотека является окончанием иерархии, а чужая библиотека обычно этому требования подчиняется. Иначе говоря, у нас нет исходников базовых классов библиотеки или каких либо ее частей, которые нам нужно изменять. Абсолютно любая часть библиотеки будет всего конечным листом для нашего проекта.
Именно только этом случае это будет достаточным.

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

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

A_A>>>

время на разработку уменьшится — экономия бабла для заказчика
AN>>ну это еще нужно доказать что время на разработку действительно Существенно уменьшится, в чем я несколько сомневаюсь.
A_A>>>

заказчик будет получать продукты быстрее — сможет выходить на рынок с новым продуктом раньше — получение новых прибылей для заказчика
A_A>>>

система будет более стабильна(будет меньше возможных багов) — вероятность потери клиентов для заказчика снизится — заказчик будет меньше терять бабла
AN>>Как система контроля версий влияет на количество багов?
A_A>Я говорю не за СКВ, а за исключение потенциальной возможности изменений исходников людьми, которые не должны этого делать в данный момент.
Насколько часто это происходит что бы могло существенно повлиять на количество багов. Тем более что речь шла о непреднамеренном исправлении. Например при периименовании чего то общего, хотя переименования можно отнести даже в плюсам, не нужно парить всем остальным мозги отчего перестало компилится. Хотя и переименование не может быть "тихим" для нескольких проектов в команде.

A_A>>>С такими аргументами нормальное руководство утверждает.
AN>>А кто, сколько времени и на что будет перестраивать все остальное?
A_A>делаете предварительные исследования в свободное от работы время(это на самом деле вам же, разработчикам, нужно )
A_A>закидываете ссылками, что это можно сделать
A_A>берете время
A_A>делаете
Предположим предыдущий вариант был сделан в течении 5-ти лет по часу в неделю считаем 250 часов, то бишь хотя бы на месяц нужно все заморозить в самом лучшем случае (Даже пусть на неделю). При этом далеко не очевидно что новая версия будет работать абсолютно идентично. Пусть даже если и делать все на игрушечной копии, после переноса обязательно будут затыки и в конце концов выяснится что новый подход не позволяет что-то сделать, что мы не заметили при анализе.
То бишь риски существуют, что так горячо лоббируемый переход дал больше новых проблем, чем решил.
Предлагаю догадатся, кто будет виновать в этом случае

Cообщение написано в << RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461>>

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

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

Q>>>>>Когда угодно. У тебя стоит ссылка на пакет версии 3.4.0.128. То, что на билд-сервере появляются версии 3.4.0.129, 3.4.0.130, etc твою программу не ломает. То же, что и со сторонними библиотеками. Скажем, используешь ты NUnit 2.5.9.10348. То, что вышла новая версия NUnit 2.5.10.11092 никоим образом на твою программу повлиять не может, пока ты сам не решишь обновиться.
AN>>>>Во внутренности NUnit мне не нужно лезть. Допустим получил я от библииотеке 0, а должно быть 5. Лезешь с отладкой и видишь что 0 ну никак не может получится. А это просто версии исходников и либы не совпадают.
A_A>>>Нужно собирать либу с такой версией, чтобы можно было найти реальные исходники.
AN>>Кто и как будет проверять версию Длл-ки при входе в функцию?
A_A>Тут поможет перегрузка функций, если уж совсем никак.
Примерчик мона?

AN>>>>>>А будет ли обеспечено, что исходники всех разработчиков будут точно сообтветствовать бинарникам.

Q>>>>>Не понял вопрос. Твоя переиспользуемая библиотека теперь выглядит так же, как не твоя переиспользуемая библиотека. От которой у тебя нет, и не нужны исходники. Все проекты всегда ссылаются на точную версию строгоименованной библиотеки.
AN>>>>Кажется, я уловил проблему. Все будет работать когда ВСЕ проекты подключены как Длл-ки (исключая вариант с отладкой кода). Но если я разработчик и мне нужно иметь актуальную версию Длл-ки, то их получается уже две версии. Одна собранная по исходникам, другая из репозитория. Дя какого-то небольшого количества еще можно все отследить, но когда и тех и других достаточно много да и еще со сложными зависимостями, остается только ждать накладки.
AN>>>>Должен быть всегда один источник и смешанная работа просто не допускается. Или всегда абсолютно все свои текущие проекты как Длл-ки с сервера или все подключения через проекты (кроме чисто библиотечных, считаемых как бы не своими). То есть если есть иерархия проектов, то вся ветка либо/либо, но никак не комбинация в ветке.
A_A>>>Да. перемешивать нельзя — бардак будет еще тот.
AN>>А как тогда работать разработчику Длл-ки? Причем один разработчик часто отвечает за более чем одну Длл-ку?
A_A>А в чем проблема-то?
A_A>Просто надо больше комунницировать, чтобы о таких изменениях все были в курсе.
А если было сказано об изменениях, но допустим забыли, что то сделать, что привело к "рассогласованию" исходников с бинарниками.

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

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

AN>>PDB то будет идти с Длл-кой, но вот гарантировать совместимость исходников с ними, да проблема.
AN>>И кстати, как сгенерить PDB без DLL-ки?

Q>http://www.rsdn.ru/forum/philosophy/4503615.aspx

Автор: Qbit86
Дата: 19.11.11

И где же там ответ на поставленный вопрос?

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

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

Z>>>А оно вам надо? И зачем вообще тратить время на загрузки "актуальных версий"?
AN>>Аргументируют, что Длл-ку имеет право изменить только "автор". А при наличии исходников, кто угодно. В результате локальная версия может не совпадать с конечной.

ГВ>Странная аргументация, очень странная. Она допустима только при одном условии: если автор работает в другой компании. Если все "авторы" работают в одной конторе — исходники должны быть доступны всем.
Речь идет о непреднамеренном изменении, причем в уже протестированной части (и "закрытой") части. А исходники и так доступны всем при двух вариантах. Только при подключении Длл-ок нужно целенаправленно лезть в иходники, а при подключенных исходниках это может сделать и прога рефакторига.

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

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

AVK>Сначала ответ — лучше исходники, так как это позволяет легче понимать код (навигация при просмотре по зависимостям не обрывается на бинарниках). Единственный момент, который стоит помнить — это влияет на производительность студии. Но если проект суммарно не очень большой, или если машина на современном уровне, то замедление обычно некритично.

AN>>Хотя некоторые имеют мнение, что при наличии решарпера и многих разработчиков лучше пользовать исключительно ДЛЛ-ки

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

Есть небольшая проблемка, что нужно иметь все исходники и без "выкрутасов". А то тестеры добрались до тестирования не public частей в своем проекте, а потом плачутся на вносимые изменения.
AN>>А то что кто то забудет актуальную версию загрузить, нужно регулировать постановлениями партии и правительства

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

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

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

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

ГВ>Задача-максимум: иметь возможность полностью пересобрать все проекты на любой машине разработчика.
Вообще то это задача минимум. Точнее, собрать конечный проект на любой машине разработчика. А пересобрать все бывает часто просто невозможно из-за ограничений по лицензии. А если даже все проекты свои, все равно могут быть ограничения. Например, для сборки одной из частей требуется "подписывать" данные в ресурсах приватным ключем.

ГВ>Но много зависит от размера исходников. Если у вас их сотни мегабайт с полусуточным циклом компиляции, то, пожалуй, полный доступ нужен только для справочных целей, а для работы достаточно периодически обновляемых бинарников.
Это уже вопрос оптимизации.
ГВ>А если сборка всех ваших исходников укладывается в час-два (сторонние библиотеки сейчас не считаем), то уместно иметь полную копию всех исходных текстов.
Я бы сформулировал следующее. Если проект находится в конечном листе иерарахии проектов, то с целью экономии времени, лучше поключать Длл-ки.

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

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

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

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

AN>И где же там ответ на поставленный вопрос? :shuffle:

Там задаётся встречный вопрос — зачем поставлять pdb с бинарниками?

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

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

AN>>И где же там ответ на поставленный вопрос?

Q>Там задаётся встречный вопрос — зачем поставлять pdb с бинарниками?
Я заметил там только "я никогда не использовал чужие pdb". А зачем вроде и так понятно. Какой есть еще стандартный и простой способ, что бы глянуть исходники кода где произошло допустим прерывание, при наличии исходного кода.

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

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

AVK>>Это регулируется техническими средствами — либо единым репозиторием, либо внешними ссылками на нужные репозитории.
AN>Репозиторий и так один, а вот забыть еще в одном месте кнопочку нажать, довольно просто.

Что значит в одном месте? Есои репозиторий единый, для апдейта нужно нажать кнопку ровно один раз ровно в одном месте.

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

AN>>А у меня есть исходники .NET Framework в проекте?
A_A>Догадываюсь, что нету.

А у меня есть. Не в проекте, правда, но студия и решарпер прекрасно их получают и позволяют по ним отлаживаться.

A_A>Так значит юзание библиотек является достаточным.

Две ноги тоже достаточны для перемещения.

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

ГВ>Задача-максимум: иметь возможность полностью пересобрать все проекты на любой машине разработчика. Но много зависит от размера исходников. Если у вас их сотни мегабайт с полусуточным циклом компиляции, то, пожалуй, полный доступ нужен только для справочных целей, а для работы достаточно периодически обновляемых бинарников. А если сборка всех ваших исходников укладывается в час-два (сторонние библиотеки сейчас не считаем), то уместно иметь полную копию всех исходных текстов.

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

ГВ>А всякие параноидальные "защиты" — это всё детсад, напакостить при желании можно где угодно. Скажем, кто-то даст кому-то по дружбе доступ к репозиторию...

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

ГВ> Короче, всё это разговоры в пользу бедных — организационные задачи техничесиким средствами не решаются.

Иногда решаются, но серпом по яйцам ради сомнительных проблем ...

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

Q>Откровенно говоря, я не знаю деталей внутреннего устройства PDB и тонкостей их распространения вместе в библиотеками. Но во всех (немногочисленных, но без исключения) NuGet-пакетах, которые таки содержали PDB-файлы, при открытии последних видны строки типа «C:\Users\VasyaPupkin\SomeProject\SomeModule\SomeClass.cs». Простите мне моё невежество, но, емнип, я никогда не использовал чужие pdb. Скажите, они вообще работают?

Работают.

Q> И если да, то как?

Так же как и свои собственные.

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

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

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

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

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

A_A>>>>1) Если нет человека с такой должностью — нужно завести должность и взять человека
AN>>>А зачем, когда можно вполен обойтись без него просто использую другой подход.
A_A>>Так в чем проблема? Используйте тот подход, который для Вас более выгоден.
AN>Хотелось бв иметь какие то критерии для выборато гото или иного подхода.
AN>Получается тогда для подхода с Длл-ками желателен отдельный человек.
там, по сути дела, работы не особо много.
Задача — автоматизировать этот процесс.
У нас в этом процессе учавствуют: svn, TeamCity и NuGet(+кастомные таски для NuGet).
svn у вас есть, если есть CI, то я думаю до получения первого стабильного фида от NuGet займет не более 40 часов для 1 человека.

A_A>>Если был бы простенький проект на 2-3 человека с 10-15 проектами — тогда бы овчинка выделки не стоила и юзание сорцов по ссылке было удобнее.
AN>Честно говоря, не вижу зависимости удобства от количества, если не учитывать какие то определенные параметры, например время компиляции (в данном случаем им можно пренебречь). То бишь нужно определится с критериями.
Ну, имхо, в будущем будет прозрачнее наблюдать версионированную длл-ку, отвечающую за какую-то функциональность,
чем лезть в svn и искать в истории своего проекта, какую же версию общего функционала он юзал
хотя, вероятность в такой нужде конечно невысокая

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

AN>>>Значит голос за Длл-ки?
AN>>А как быть тогда с совмещением ссылок на Длл-ки и проекты?
A_A>>Можно по-детальней?
AN>Допустим есть решение использовать подключение через Длл-ки, тогда абсолютно все проекты обязаны подключаться как Длл-ки, а Длл-ки браться из одного места. AN>>Что тогда делать разработчику Длл-ки?
AN>Ведь ему вначале нужно иметь локальную копии для проверки/тестирования, а наличие копии входит в противоречие с требованием "одного источника". Точнее, это AN>>требование является необходимым для "внутренностей" ветки иерархии проектов/Длл-ок. Окончания веток- листики этому требования не подчиняются. Их можно AN>>включать как нужно в данной ситуациии.
Здесь немного не ясно.
Разработчик длл-ки ничего и никого не ждет(это ж будет какой-то общий функционал) — наоборот, его все ждут
Копия чего ему нужна?
Он делает новый функционал согласно появившимся требованиям.
Если функционал еще не существует — что проверять-то тогда?
A_A>>Что делать разработчику именно этой Длл-ки в проекте?
A_A>>тут есть два варианта:
A_A>>1)Длл-ка принадлежит другой команде — вносится тикет на создание в ней фичи и ждем, когда эта команда нам выдаст новую длл-ку.
AN>Тут видимо подразумевается, что проект принадлежит конечному листу иерархии проектов.
A_A>>2)длл-ка наша — мы сами с ней делаем что хотим и не ждем никогда
AN>Вот именно ждать и нужно. "Владелец" Длл-ки нужен вначале найти и исправить проблему, а остальные ждут пока будет готова очереная порция Длл-ок.
Так в варианте с исходниками тоже ждать остальным придется.
Если вопрос во времени билда новой версии и доставка ее всем нуждающимся — то без автоматизации — никак.
Считаем:
Время билда — время компиляции проекта (+- работа CI — но там секунды)
Время доставки — изменение строки в конфиге NuGet, и работа батника — минута делов
AN>>Хотя можно AN>>сказать, берите файл х проекта У. К тому-же разработчик при создании локальной Длл-ки, должне пользоваться "другим источником" — исходниками. AN>>А при использовании второго источника должна быть гарантия, что эти два истоника синхронизированы. К тому нужно иметь и локалный механизм "подмены" Длл-ок.
Да, пока автоматизацию длл-ок не сделаете — однозначно юзать только ссылки на исходники, а то времени и нервов впустую будет уходить много
AN>>И что делать остальным когда исходники уже в репозитории, но бильд длл-ок еще не готов. Ждать пока не будет все готово и после все брать?
AN>>А если в это же время закоммитились другие изменения, которые нужно пока избежать? (Допустим они исправили генерацию данных, и неправильные данные для теста уже получить просто невозможно)
A_A>>Это сложный вопрос. Опять же:
A_A>>1) Если длл-ка ваша — то вы всегда в курсе всех изменений
AN>Даже если и в курсе, нужно отслеживать и исходники и бинарники (в случае подключения Длл-ок), да и еще желательно знать зависимости бинарников.
Зачем что-то отслеживать?
Один обновил длл-ку -> сообщил нуждающимся номер версии и суть обновлений -> они скачали и юзают.
А вот если будут проблемы и захочется найти виновного — то разбираться придется со своим проектом, и версией исходников длл-ки
(в соответствии версии длл-ки исходникам мы ведь не сомневаемся — это ж происходит без участия человека)
A_A>>2) Тут надо отслеживать все изменения с текущей версии по ту, которую хотите заюзать.
A_A>>То есть нужно отслеживать два источника: исходники и бинарники, и к тому же учитывать иерархию бинарников.
A_A>>1) Если длл-ка ваша — вы следитие только за сорцами — на версии вам пофиг
AN>Пофиг не могут быть, ведь подключаются только Длл-ки. (Не говорим о "конечных листиках")
A_A>>2) Следите только за изменениями в функционале и версиями — на сорцы вам пофиг
AN>на сорцвы не пофиг, откуда бильдить локальные версии на время правки?
насколько я понял, длл-ка принадлежит "нашей" команде, так что этот пункт уже не имеет значение

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

AN>>>А кто, сколько времени и на что будет перестраивать все остальное?
A_A>>делаете предварительные исследования в свободное от работы время(это на самом деле вам же, разработчикам, нужно )
A_A>>закидываете ссылками, что это можно сделать
A_A>>берете время
A_A>>делаете
AN>Предположим предыдущий вариант был сделан в течении 5-ти лет по часу в неделю считаем 250 часов, то бишь хотя бы на месяц нужно все заморозить в самом лучшем случае (Даже пусть на неделю). При этом далеко не очевидно что новая версия будет работать абсолютно идентично. Пусть даже если и делать все на игрушечной копии, после переноса обязательно будут затыки и в конце концов выяснится что новый подход не позволяет что-то сделать, что мы не заметили при анализе.
AN>То бишь риски существуют, что так горячо лоббируемый переход дал больше новых проблем, чем решил.
AN>Предлагаю догадатся, кто будет виновать в этом случае
Делаете пилотные проекты(лучше скопировать текущие самые сложные, с наибольшим количеством зависимостей) — на них играетесь
Потом постепенно переводите текущие на новую систему.
Риски всегда есть. Чтобы о них узнать заранее нужно проводить ресерч.
А по поводу переходить или нет — выписываешь в список плюсы и минусы существующей системы и новой(насколько возможно собрать информацию)
и будет ясно.

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