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

[...]

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

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

ГВ>>>>А как он узнает, что бага в такой-то библиотеке а не в его коде?
[...]
A_A>Более реальный, когда ловит IndexOutOfRangeException

Это может указывать и на ошибку в своём коде.

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

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

ИМХО, это означает, что надо следить за тем, как используется программа рефакторинга (я сейчас не помню, позволяет ли решарпер ограничить изменения только одним проектом в солюшене).

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

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

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

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

А ключ только у доверенного? По-моему, это тоже слегка перебор.

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

Всё, о чём мы говорим, сводится к оптимизации.

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

Да экономия времени-то не ахти какая большая, прямо скажем. Меня смущают в подключении только DLL возможные конфликты платформ (x86, x64, AnyCPU, etc.) и конфигураций (Debug, Release). Второе в меньшей степени, конечно.

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

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

A_A>>...ловит IndexOutOfRangeException

ГВ>Это может указывать и на ошибку в своём коде.

Пусть тогда NullReferenceException. Это исключение, которое не должно покидать пределов сборки, однозначно свидетельствует об ошибке в библиотеке.

Ну и далее. Если единственная предполагаемая реакация — «написать feature request/bug report разработчику и ждать update/bugfix, временно используя workaround» (даже если разработчик — тот же или соседний коллектив), то в такой модели разрабатываемая библиотека ничем не отличается от third party библиотек (которые в общем случае поставляются без исходников).

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

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

A_A>>Плохое я сделал ТЗ в начале, не детализированное :crash:
A_A>>Давайте уточним. :)
A_A>>Заказчик: министр внутренних дел...

ГВ>Я так понял, что ты хотел проиллюстрировать известную поговорку про две российские беды, нет?

Неудачная метафора подобна котёнку с дверцей © Я к тому, что аналогия, кажется, себя изжила и уходит в какие-то дебри, обрастая не относящимися к исходному вопросу подробностями :)

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

AN>К сожалению это на аргумент в споре не тянет Меня интересуют прежде всего аргументы, которые возможно я забыл/не заметил.

Пользы нет, вред есть. Какие еще аргументы нужны?

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

AN>Аргументируют, что Длл-ку имеет право изменить только "автор".

Это проблема. А если автор в командировке или на больничном?

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

Что мешает разработчикам это сказать? Словами? Не правьте чужие библиотеки. Они обычно ребята умные, понимают.

А если вдруг надо на одну либу посадить двоих разработчиков, не успевает один, держит всю команду. Как они будут мерджить бинарную dll? Правки то они начнут вносить одновременно. Первый разработчик пофиксил баг А, второй баг Б. Каждый выложил новую версию.

AN>В результате локальная версия может не совпадать с конечной.

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

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

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

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

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

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

Я имел дело с 5ти уровневой структурой библиотек с бинарниками в externals для плюсов. Больше не буду и такое проскочит только через мой труп. Там где я сейчас, есть один проект вынесенный в бинарную зависимость в перфорсе. Я прекрасно понимаю почему (его сложно собирать и лицензия там под сомнением), но он создает в работе серьезные проблемы. По поводу свн еще могу добавить что после административных изменений на сервере номера ревизий могут и поменяться и весь этот карточный домик сложится в один момент.

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

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

SD>Я имел дело с 5ти уровневой структурой библиотек с бинарниками в externals для плюсов. Больше не буду и такое проскочит только через мой труп.

Потому я и говорю не «использовать», а «пристально посмотреть» :) Следовало больше акцентировать внимание на второй части: «И вообще, повлиять на руководство в сторону приобщения к правильным и удобным инструментам.»

SD>Я имел дело с 5ти уровневой структурой библиотек с бинарниками в externals для плюсов. Больше не буду и такое проскочит только через мой труп.

Я предлагал двухуровневую структуру, при которой репозитории «с мясом» не содержат субрепозиториев. Т.е. есть два типа: листовые репозитории (без субрепозиториев, но с исходниками), и тонкие мастер-репозитории (без исходников, служат для увязывания воедино других листовых модулей). Репозитории с «мясом» являются сиблингами друг по отношению к другу, даже если зависят один от другого как модули.

See also: Use a thin shell repository to manage your subrepositories.

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

A_A>А в чем профит от отладки по исходникам .NET Framework?

В ускорении поиска ошибки.

A_A>Пересборка его все равно не имеет смысла.

А зачем его пересобирать?

A_A>Если не выполняет, то по какой причине:
A_A>

если я передаю некорректные входные параметры, то какие именно и какие границы корректности

Вот тут исходники и помогут.

A_A>

если по вине библиотеки, то это уже не моя проблема

Это как посмотреть. Багу то тебе надо устранить, а не МС.

A_A>Во всех случаях я не вижу практического смысла в наличии исходников.

Сочувствую.

... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>

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

Q>Неудачная метафора подобна котёнку с дверцей © Я к тому, что аналогия, кажется, себя изжила и уходит в какие-то дебри, обрастая не относящимися к исходному вопросу подробностями

Она не то чтобы себя изжила, она с самого начала не годилась. Как и любая другая аналогия.

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

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

ГВ>Да экономия времени-то не ахти какая большая, прямо скажем.
Но она есть — и это факт.
Когда ты по 10-30 раз на день делаешь локальные билды проектов, то начинаешь ценить любую секунду.
Да и меньшее количество проектов в солюшене -> однозначный профит.
Время загрузки солюшна уменьшается -> меньше парсить и проверять студии -> профит.
Время навигации по коду уменьшается -> профит.
Да и вообще, лично мне, больше глазу приятно, когда меньше каких-то единиц сущностей(будь то файлы, проекты, папки -> маловажно) в любой момент времени
над любой задачей.
ГВ>Меня смущают в подключении только DLL возможные конфликты платформ (x86, x64, AnyCPU, etc.) и конфигураций (Debug, Release). Второе в меньшей степени, конечно.
Мы, собственно, всегда под AnyCPU в Release и собираем — зачем иначе?

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

AN>>Аргументируют, что Длл-ку имеет право изменить только "автор".

Z>Это проблема. А если автор в командировке или на больничном?
У нас командная разработка или как?
Команда у нас коммуникативная?
В чем проблема?

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

Z>Что мешает разработчикам это сказать? Словами? Не правьте чужие библиотеки. Они обычно ребята умные, понимают.

Z>А если вдруг надо на одну либу посадить двоих разработчиков, не успевает один, держит всю команду. Как они будут мерджить бинарную dll?
А зачем мерджить бинарную длл?
Z>Правки то они начнут вносить одновременно. Первый разработчик пофиксил баг А, второй баг Б.
+1 — налицо командная работа
Z>Каждый выложил новую версию.
Нет. Это в корне неправильно. Они что в разных полушариях земли живут без средств коммуникации?
Первый кто готов — говорит второму, что закончил и залился.
Второй отвественен за релиз новой версии для всех нуждающихся.


AN>>В результате локальная версия может не совпадать с конечной.

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

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

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

Q>Пусть тогда NullReferenceException. Это исключение, которое не должно покидать пределов сборки, однозначно свидетельствует об ошибке в библиотеке.

Q>Ну и далее. Если единственная предполагаемая реакация — «написать feature request/bug report разработчику и ждать update/bugfix, временно используя workaround» (даже если разработчик — тот же или соседний коллектив), то в такой модели разрабатываемая библиотека ничем не отличается от third party библиотек (которые в общем случае поставляются без исходников).

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

Мы применяли такой подход (и были довольны ), пока у нас не появился NuGet.
Делали svn:externals на всегда последнюю ревизию исходников из транка и я сам бывало так фиксил баги.
Но потом у нас появился NuGet и мы решили(командно) использовать либы всегда.

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

Всегда ясно видно, что в проекте есть ссылка на нестандартную(не из .NET Framework) либу. Все нестандартные либы качаются с помощью батника.
Т.е. мне не нужно лезть ни в какие svn-свойства папки и смотреть, откуда же они здесь появляются после апдейта.

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

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

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

A_A>>Если не выполняет, то по какой причине:
A_A>>

если я передаю некорректные входные параметры, то какие именно и какие границы корректности

AVK>Вот тут исходники и помогут.

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

A_A>>

если по вине библиотеки, то это уже не моя проблема

AVK>Это как посмотреть. Багу то тебе надо устранить, а не МС.

И каким образом ты пользуешься результатами устранения багов в исходниках .Net Framework?

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

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

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

AVK>Что значит в одном месте? Есои репозиторий единый, для апдейта нужно нажать кнопку ровно один раз ровно в одном месте.
Во первых, в репо не один проект. Во вторых, в ветке проекта, не только исходники, но и все сопутствующее.
В третьих, скорость. В четвертых, все слепо коммитить запрещено. Ну и в основном, работа происходит через плагин к студии. Если брать с роота обновления, то будет длиться довольно долгое время.
Но дело ведь не в чтении, но и в записи.

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

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

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

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

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

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

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

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

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

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

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

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