Здравствуйте, 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>>