Re[2]: Минусы
От: Qbit86 Кипр
Дата: 19.11.11 13:43
Оценка: 2 (2) +1
Здравствуйте, Andrii_Avramenko, Вы писали:

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


Минус не только один. Среди прочих:
  • К задаче версионирования и публикации исходников добавляется задача версионирования и доставки разработчикам производных артефактов.
  • Проще отлаживать, когда исходники рядышком.
  • Глаза у меня добрые, но рубашка — смирительная!
    Re[8]: Две российские беды
    От: Qbit86 Кипр
    Дата: 21.11.11 04:16
    Оценка: +2 :)
    Здравствуйте, Геннадий Васильев, Вы писали:

    A_A>>Плохое я сделал ТЗ в начале, не детализированное :crash:

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

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


    Неудачная метафора подобна котёнку с дверцей © Я к тому, что аналогия, кажется, себя изжила и уходит в какие-то дебри, обрастая не относящимися к исходному вопросу подробностями :)
    Глаза у меня добрые, но рубашка — смирительная!
    Re: Как лучше подключать подпроекты - DLL или исходники чере
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 19.11.11 19:09
    Оценка: 2 (2)
    Здравствуйте, AlexNek, Вы писали:

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

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


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

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


    Это регулируется техническими средствами — либо единым репозиторием, либо внешними ссылками на нужные репозитории.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re: Как лучше подключать подпроекты - DLL или исходники чере
    От: Ziaw Россия  
    Дата: 19.11.11 13:08
    Оценка: +2
    Здравствуйте, AlexNek, Вы писали:

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

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

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

    Зато факт, что используемый реально код не соответствует исходникам вызывает бешенную ненависть после кучи времени потраченного на детект ситауции. А оно вам надо? И зачем вообще тратить время на загрузки "актуальных версий"?
    Re[16]: NullReferenceException
    От: Qbit86 Кипр
    Дата: 21.11.11 04:09
    Оценка: +2
    Здравствуйте, Геннадий Васильев, Вы писали:

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


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


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


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

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

    Если же предполагается, что программист может по ходу разработки менять не только свой клиентский код, но и править библиотечный (с теми или иными требованиями к совместимости с другим потенциально существующим клиентским кодом), то предпочтительней иметь исходники тут же, т.е. ссылаться на проекты. Иными словами, в качестве подключаемого модуля рассматривать не бинарный, а исходный код. Имхо.
    Глаза у меня добрые, но рубашка — смирительная!
    Re: Модули
    От: Qbit86 Кипр
    Дата: 19.11.11 12:55
    Оценка: 5 (1)
    Здравствуйте, 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).
    Глаза у меня добрые, но рубашка — смирительная!
    Re[4]: Как лучше подключать подпроекты - DLL или исходники ч
    От: WolfHound  
    Дата: 19.11.11 15:29
    Оценка: 1 (1)
    Здравствуйте, Andrii_Avramenko, Вы писали:

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

    Он много что позволяет, но все через задний проход с массой геморроя.

    A_A>Система контроля версий здесь непричем.

    Еще как причем.
    Чтобы так работать нужно постоянно делать бранчи.
    Ибо когда правишь код во внешнем модуле, сразу же должен создаваться новый бранч для этого кода.
    А потом уже его будут в спокойной обстановке сливать с основным кодом.
    А в SVN с бранчами страшный геморрой.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[6]: Как лучше подключать подпроекты - DLL или исходники ч
    От: WolfHound  
    Дата: 19.11.11 16:41
    Оценка: 1 (1)
    Здравствуйте, Andrii_Avramenko, Вы писали:

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

    Любая распределенная.

    A_A>Я хочу сделать новую версию общей части для одного клиента:

    В это время другой программист захотел сделать тоже самое.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[12]: Как лучше подключать подпроекты - DLL или исходники
    От: WolfHound  
    Дата: 19.11.11 19:22
    Оценка: 1 (1)
    Здравствуйте, Andrii_Avramenko, Вы писали:

    A_A>Процесс коде-ревью встроенный в СКВ?

    A_A>Прикольно.
    A_A>Тогда распределенные СКВ рулят.
    Он не то чтобы встроен, просто распределенные СКВ очень хорошо к этому приспособлены.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[7]: Pdb
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 20.11.11 18:18
    Оценка: 1 (1)
    Здравствуйте, Qbit86, Вы писали:

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


    Работают.

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


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

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


    Если ты про абсолютный путь, то студия умеет его заменять. При первой необходимости она спросит тебя, где находится файл MySuperClass.cs и после этого будет брать исходники оттуда.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[10]: NuGet
    От: Qbit86 Кипр
    Дата: 21.11.11 20:05
    Оценка: 1 (1)
    Здравствуйте, AlexNek, Вы писали:

    AN>Глянул сегодня NuGet — плагин к 2010, уже значит не подходит.


    Нет, то плагин для среды. Для сборки же проектов Студия, разумеется, не нужна (да и откуда ей взяться на билд-сервере). Есть консольная утилита, состоящая из одного файлика — nuget.exe. Его достаточно по крайней мере для всего.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[10]: NuGet
    От: Andrii_Avramenko Украина  
    Дата: 21.11.11 20:13
    Оценка: 1 (1)
    Здравствуйте, AlexNek, Вы писали:

    AN>Глянул сегодня NuGet — плагин к 2010, уже значит не подходит.

    Этот плагин не нужен.
    NuGet юзается как хранилище модулей.
    Загружаешь в него через msbuild + CI.
    Вытягиваешь — через батник + кастомные таски.
    У нас так
    Re[6]: Солюшены
    От: Qbit86 Кипр
    Дата: 22.11.11 05:37
    Оценка: 1 (1)
    Здравствуйте, Геннадий Васильев, Вы писали:

    ГВ>Согласен. Я бы всё же посоветовал присмотреться к такому варианту:

    ГВ>- "Эталонный" солюшен содержит полный комплект ссылок на проекты, но референсы расставлены на бинарные сборки (не на сами проекты);
    ГВ>- Локальные солюшены каждый может сделать какие угодно, не выкладывая их на SVN: проекты уже готовы к изолированному использованию.

    Информация о том, что «референсы расставлены на бинарные сборки (не на сами проекты)», хранится не в солюшенах, а в MsBuild-скриптах сборки (в csproj-проектах). Солюшены по большему счёту нафиг не нужны, для последних проектов у нас они даже в репозтории с исходниками не хранятся.

    Есть другой вариант (я его, возможно, попробую в будущем). Можно настроить условные ссылки. Т.е. при каком-то определённом окружении будет выбираться <Reference> или <ProjectReference> в зависимости от определённого свойства (msbuild property).
    Глаза у меня добрые, но рубашка — смирительная!
    Re[7]: MSBuild Conditions
    От: Qbit86 Кипр
    Дата: 22.11.11 10:25
    Оценка: 1 (1)
    Здравствуйте, AlexNek, Вы писали:

    AN>Так референсы то в проектах сидят. Приходится делать копию проекта с другим именем и другим солюшен.


    Вообще-то можно в одном проекте подключить библиотеку и как проект, и как бинарник таким образом, чтобы фактический вариант ссылки легко переключался, скажем, через MSBuild Property, можно даже в локальном приватном user-файле. Что-то вроде:
    <Reference Condition="'$(MyVariable)' == 'true'">
      ...
    </Reference>
    <ProjectReference Condition="'$(MyVariable)' != 'true'">
      ...
    </ProjectReference>
    Глаза у меня добрые, но рубашка — смирительная!
    Re[30]: Апдейт
    От: Qbit86 Кипр
    Дата: 26.11.11 08:34
    Оценка: 1 (1)
    Здравствуйте, Andrii_Avramenko, Вы писали:

    A_A>Выходит, во время каждого локального билда в студии дергается апдейт NuGet и он проверяет каждый фид?


    Апдейт работает инкрементально. Т.е. если пакет нужной версии уже выкачан в папку Packages, то NuGet даже в интернет не лезет.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[10]: Как лучше подключать подпроекты - DLL или исходники
    От: Andrii_Avramenko Украина  
    Дата: 27.11.11 14:12
    Оценка: 1 (1)
    Здравствуйте, Геннадий Васильев, Вы писали:

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


    AVK>>>А зачем всякую фигню на сотни мег класть рядом с исходниками?

    A_A>>Никакой фигни — куча сорцов, причем процентов 70 — легаси кода.

    ГВ>Папки на сотни мегабайт исходников легаси-кода? В воображении сразу рисуется что-то вроде хардкорного C и C++ имени VC6...


    На днях приведу скриншот
    Re[2]: Плюсы
    От: Qbit86 Кипр
    Дата: 19.11.11 13:36
    Оценка: +1
    Здравствуйте, Andrii_Avramenko, Вы писали:

    A_A>Плюсы:


    Перечисленных плюсов можно добиться и ссылаясь на исходники.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[2]: Как лучше подключать подпроекты - DLL или исходники ч
    От: WolfHound  
    Дата: 19.11.11 13:37
    Оценка: +1
    Здравствуйте, Andrii_Avramenko, Вы писали:

    A_A>ИМХО, однозначно только использовать подключение библиотек.

    хъ
    Это все прекрасно делается с нормальными системами контроля версий
    Автор: Qbit86
    Дата: 19.11.11
    .
    Поставь git или hg и будет тебе счастье.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[4]: NuGet
    От: Qbit86 Кипр
    Дата: 19.11.11 14:06
    Оценка: +1
    Здравствуйте, 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, когда готовы начать разрешать потенциально появившиеся конфликты из-за отсутствия обратной совместимости версий разрабатываемой переиспользуемой библиотеки.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[4]: Плюсы
    От: Qbit86 Кипр
    Дата: 19.11.11 14:10
    Оценка: +1
    Здравствуйте, Andrii_Avramenko, Вы писали:

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


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

    A_A>Пример:

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

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


    Поломали сервер в своей ветке. Остальные клиенты продолжают использовать стабильную версию исходников сервера, как в случае, если бы они ссылались на предыдущую версию бинарника сервера.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[3]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 19.11.11 19:07
    Оценка: +1
    Здравствуйте, AlexNek, Вы писали:

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

    AN>На это отвечают — прищучим всех Во что слабо верится.

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

    Z>>А оно вам надо? И зачем вообще тратить время на загрузки "актуальных версий"?

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

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

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


    Вот именно.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[3]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 19.11.11 21:01
    Оценка: +1
    Здравствуйте, Andrii_Avramenko, Вы писали:

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

    A_A>Кстати вот на перекрестках есть светофоры — они предназначены разруливать организационную задачу — ПДД

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

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


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

    A_A>[...]

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

    Плохая аналогия.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[3]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 20.11.11 16:53
    Оценка: +1
    Здравствуйте, AlexNek, Вы писали:

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

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

    Что значит в одном месте? Есои репозиторий единый, для апдейта нужно нажать кнопку ровно один раз ровно в одном месте.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[2]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 20.11.11 18:09
    Оценка: +1
    Здравствуйте, Геннадий Васильев, Вы писали:

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


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

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


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

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


    Иногда решаются, но серпом по яйцам ради сомнительных проблем ...
    ... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[3]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Ziaw Россия  
    Дата: 21.11.11 08:32
    Оценка: +1
    Здравствуйте, AlexNek, Вы писали:

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


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

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


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

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

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


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

    Бинарные ссылки допустимы только для внешних, по отношению к проекту зависимостей.
    Re[5]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 21.11.11 19:58
    Оценка: +1
    Здравствуйте, AlexNek, Вы писали:

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

    AN>Во первых, в репо не один проект.

    Ну и что? Тебе места на диске жалко?

    AN> Во вторых, в ветке проекта, не только исходники, но и все сопутствующее.


    Не понял. И при чем тут это сопутствующее?

    AN>В третьих, скорость.


    Скорость чего?

    AN> В четвертых, все слепо коммитить запрещено.


    Ну так и не надо все слепо коммитить.

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


    И что?

    AN> Если брать с роота обновления, то будет длиться довольно долгое время.


    Да ну нафик. Долгое время это сколько? 1 минуту? 2?

    AN>Но дело ведь не в чтении, но и в записи.


    И что с ней не так?
    ... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[9]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Ziaw Россия  
    Дата: 28.11.11 03:08
    Оценка: +1
    Здравствуйте, Andrii_Avramenko, Вы писали:

    Z>>Это по вашему сценарию:

    A_A>>>Нет. Это в корне неправильно. Они что в разных полушариях земли живут без средств коммуникации?
    A_A>>>Первый кто готов — говорит второму, что закончил и залился.
    A_A>>>Второй отвественен за релиз новой версии для всех нуждающихся.
    A_A>Дык, я и не отрицаю-то
    A_A>Кто ждет-то и чего ждет, лучше объясните.

    Коллега ждет, пока первый ему скажет, что готов. Либо что залил. Чтобы начать править следующий баг.

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


    Z>>Эта фраза говорит о вашей полной некомпетентности в вопросах сборки. Зачем лезть с безапелляционными заявлениями в темы о которых вы практически ничего не знаете?

    A_A>"А судьи кто?" (С)
    A_A>А можно по-конкретней?

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

    A_A>>>Ну, и любимый кейс:


    A_A>>>Блин, какого фига на CI тесты падают, а локально работают?


    Z>>Видимо очень любимый, раз не желаете с ним расставаться.

    A_A>А Вы как с ним расстались?

    Легко, идентичное окружение дает идентичные результаты. Не будет нескольких версий — не будет расхождений в тестах.
    Re[10]: Как лучше подключать подпроекты - DLL или исходники
    От: Andrii_Avramenko Украина  
    Дата: 28.11.11 06:37
    Оценка: :)
    Здравствуйте, Ziaw, Вы писали:

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


    Z>>>Это по вашему сценарию:

    A_A>>>>Нет. Это в корне неправильно. Они что в разных полушариях земли живут без средств коммуникации?
    A_A>>>>Первый кто готов — говорит второму, что закончил и залился.
    A_A>>>>Второй отвественен за релиз новой версии для всех нуждающихся.
    A_A>>Дык, я и не отрицаю-то
    A_A>>Кто ждет-то и чего ждет, лучше объясните.

    Z>Коллега ждет, пока первый ему скажет, что готов. Либо что залил.

    Нет, не ждет. Он занимается своей работой. Зачем ему кого-то ждать?
    Z>Чтобы начать править следующий баг.
    Откуда у нас "вдруг" взялся какой-то следующий баг?
    Что это за девелоперы, что при правке одного бага, они "рождают" другие?


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


    Z>>>Эта фраза говорит о вашей полной некомпетентности в вопросах сборки. Зачем лезть с безапелляционными заявлениями в темы о которых вы практически ничего не знаете?

    A_A>>"А судьи кто?" (С)
    A_A>>А можно по-конкретней?

    Z>Вообще все предложение выглядит как "мы только ложкой банка огурцы".

    Какое конкретно предложение?
    Z>Вкратце, msbuild не предназначен для модификации скриптов.
    И для работы с .msbuild файлами не предназначен?
    Вот это "компетентность"
    Z>И сложно обойти его использование по прямому назначению, программируя под .net.
    А Вы пытались обойти? Сочувствую.
    MSBuild The Microsoft Build Engine (MSBuild) is a platform for building applications.
    Выходит, что мы, юзая систему для автоматизации сборки приложений, которая предназначена для автоматизации сборки приложений,
    являемся некомпетентными?
    В логике Вам не откажешь.

    A_A>>>>Ну, и любимый кейс:

    A_A>>>>Блин, какого фига на CI тесты падают, а локально работают?

    Z>>>Видимо очень любимый, раз не желаете с ним расставаться.

    A_A>>А Вы как с ним расстались?

    Z>Легко, идентичное окружение дает идентичные результаты.

    Идентичное окружение — это когда сам для себя в своей песочнице пишешь проект, который никто юзать не будет.
    Z>Не будет нескольких версий — не будет расхождений в тестах.
    Расхождений в тестах у нас из-за версионности компонентов никогда и не было.
    И откуда Вы это придумали?
    Re[11]: Image hosting
    От: Qbit86 Кипр
    Дата: 28.11.11 19:00
    Оценка: +1
    Здравствуйте, Andrii_Avramenko, Вы писали:

    A_A>TempTrunk.jpg


    Для выкладывания картинок предпочтительнее использовать не файлообменник общего назначения с рекламой увеличения длины интеллекта, а хостинги картинок, например:
    http://imgur.com/
    http://tinypic.com/
    http://imageshack.us/
    Глаза у меня добрые, но рубашка — смирительная!
    Re[15]: Как лучше подключать подпроекты - DLL или исходники
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 28.11.11 20:32
    Оценка: +1
    Здравствуйте, AlexNek, Вы писали:

    AN>"Поигрался он" пару минут, ничего не получается.


    Значит такая у него компетенция.

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


    И все конфиги, батники, логи и что там еще разработчик нешарабельного наплодил — все коту под хвост Похоже, на админе твой работодатель тоже съэкономил.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Как лучше подключать подпроекты - DLL или исходники через пр
    От: AlexNek  
    Дата: 19.11.11 12:25
    Оценка:
    Для MSVC, под виндами, С#, winforms, если что.
    Временами на работе возникают дискуссии, что подключать лучше в солюшин как внешние ссылки при наличии исходников — DLL-ки или проекты.
    Понятно что абсолютно однозначного ответа нет, зависит от конкретной ситуации. Допустим, когда исходники стабильные и практически не меняются, либо от кого-то другого, то видимо DLL-ки с PDB (и отдельными исходниками для отладки) лучше. По крайней мере, нет никакой возможности изменить непреднамеренно код.

    Речь же идет исключительно об исходниках текущего проекта, собираемого из многих подпроектов. Просто часто сталкивался, когда исходники чуть чуть отличаются от ДЛЛ-ки и фиг поймешь отчего вдруг не работает/вылетает. Хотя некоторые имеют мнение, что при наличии решарпера и многих разработчиков лучше пользовать исключительно ДЛЛ-ки, несмотря на наличие в солюшин всех требуемы подпроектов с исходниками. А то что кто то забудет актуальную версию загрузить, нужно регулировать постановлениями партии и правительства
    Хотелось бы услышать различные мнения за и против каждого из подходов, чтобы не ругатся до состояния "пены у рта".
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re: Как лучше подключать подпроекты - DLL или исходники чере
    От: MozgC США http://nightcoder.livejournal.com
    Дата: 19.11.11 12:38
    Оценка:
    ИМХО чаще подключается DLL. Навскидку приходят такие минусы подключения исходников стороннего проекта:
    — Скорее всего исходников подключаемого проекта не окажется в репозитории, что может оказаться проблемой при checkout'е на другом/чистом компьютере
    — Если хранить подключаемые проекты в репозитории, то это увеличивает размер репозитория (а необходимость подключения стороннего проекта через исходники может быть сомнительна)
    — Увеличится время компиляции проекта
    — Возможно, что нужна стабильная версия подключаемого проекта. Допустим, я в своем проекте А использую проект Васи — Б (может и сам в нем тоже участвую), проект Васи Б тоже под контролем версий у меня. Тогда, если вдруг Вася что-то изменит в проекте Б, а я сделаю update проекта Б, то в моем проекте А может что-то поломаться или придется что-то менять.
    Re[2]: NuGet
    От: Qbit86 Кипр
    Дата: 19.11.11 13:13
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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


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

    Сам по себе пакетный менеджер NuGet для общеизвестных библиотек очень удобная штука, не нарадуюсь.
    Глаза у меня добрые, но рубашка — смирительная!
    Re: Как лучше подключать подпроекты - DLL или исходники чере
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 13:31
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

    AN>Для MSVC, под виндами, С#, winforms, если что.

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

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

    Минус только один — увеличивается время внесения изменений в сервер и процесс уведомления клиентов, чтобы они заюзали обновленную версию сервера
    (это даже еще не означает что они должны немедленно использовать обновление).
    Плюсы:
  • Возможность внесения любых изменений в сервер за фиксированное время, без рисков что эти изменения поломают какого-то клиента
  • Версионирование сервера — возможность для разных клиентов юзать разные версии сервера
  • Время на внесение изменений в клиент с использованием стабильной версии сервера всегда фиксированно и не имеет рисков из-за сервера
  • Возможность быстрой замены новой версии сервера, в которой вдруг возникла неожиданная критическая ошибка, на старую и проверенную версию
    сервера для конечного пользователя — этот пункт самый важный, поскольку деньги на разработкудают именно конечные пользователи всей системы).
  • Re[2]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AlexNek  
    Дата: 19.11.11 13:48
    Оценка:
    Здравствуйте, MozgC, Вы писали:

    MC>ИМХО чаще подключается DLL.

    Я лично сталкивался чаще с обратным, причем часто вначале подключали Длл-ки, а после затыкав переходили на проекты.
    MC>Навскидку приходят такие минусы подключения исходников стороннего проекта:
    MC>- Скорее всего исходников подключаемого проекта не окажется в репозитории, что может оказаться проблемой при checkout'е на другом/чистом компьютере
    В обсуждаемом варианте они всегда есть.
    MC>- Если хранить подключаемые проекты в репозитории, то это увеличивает размер репозитория (а необходимость подключения стороннего проекта через исходники может быть сомнительна)
    размер бинарниками будет несравненно больше, вес проекты "свои".
    MC>- Увеличится время компиляции проекта
    Только первый раз, да и нет сотни гигантских подпроектов.
    MC>- Возможно, что нужна стабильная версия подключаемого проекта. Допустим, я в своем проекте А использую проект Васи — Б (может и сам в нем тоже участвую), проект Васи Б тоже под контролем версий у меня. Тогда, если вдруг Вася что-то изменит в проекте Б, а я сделаю update проекта Б, то в моем проекте А может что-то поломаться или придется что-то менять.
    Вообще то это и нужно как можно раньше определить. Или иначе, нельзя тогда вообще иметь исходников других продключаемых проектов.
    Если исходники Васи все же пользуются, а они не будут совпадать с Длл-ков, то последствия могут быть непредсказуемыми.
    А несовпадение довольно просто. Или мы забыли взять последнюю версию всего или Вася забыл обновить библиотеку или обновил не на последнюю версию.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[2]: Модули
    От: AlexNek  
    Дата: 19.11.11 13:48
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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


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


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

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

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

    Есть только SVN.


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

    Во время разработки обычно никто после изменения пары строчек не меняет номер версии. Это прерогатива "выпускающего"
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[2]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AlexNek  
    Дата: 19.11.11 13:48
    Оценка:
    Здравствуйте, Ziaw, Вы писали:

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


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

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

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

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

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

    На это отвечают — прищучим всех Во что слабо верится.
    Z>А оно вам надо? И зачем вообще тратить время на загрузки "актуальных версий"?
    Аргументируют, что Длл-ку имеет право изменить только "автор". А при наличии исходников, кто угодно. В результате локальная версия может не совпадать с конечной.
    Хотя если все билдится из репозитория, то это уже относительно простая проблема разработчика не иметь изменений в "чужих" проектах. При чекине видно на раз.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[3]: NuGet
    От: AlexNek  
    Дата: 19.11.11 13:48
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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


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


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

    Кто будет их создавать и когда? А также когда их брать? А будет ли обеспечено, что исходники всех разработчиков будут точно сообтветствовать бинарникам.
    Допустим в 16:00 создали либы по репозиторию, а в 16:15 кто то залил изменения в репозиторий. В итоге те кто возьмут пакет и обновление репозитория в 16:20 получат несоответсвие.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[3]: Плюсы
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 13:50
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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


    A_A>>Плюсы:


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


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

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

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

    ссылки на версионированные библиотеки являются защитой от этих возможных рисков в будущем.
    Re[3]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 13:53
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

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


    A_A>>ИМХО, однозначно только использовать подключение библиотек.

    WH>хъ
    WH>Это все прекрасно делается с нормальными системами контроля версий
    Автор: Qbit86
    Дата: 19.11.11
    .

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

    SVN тоже позволяет подключать исходники как SVN:externals.
    Система контроля версий здесь непричем.
    Re[3]: Модули
    От: Qbit86 Кипр
    Дата: 19.11.11 13:56
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

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

    AN>Есть только SVN.

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

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


    Версии (major, minor, maintenance) — да. А номер build'а (у нас это номер ревизии того локального клона репозитория, с которого идёт сборка на билд-сервере; нужна только для удобства) и атрибут с чейнджсетом (скажем, 111c07b94e72, для уникальной идентификации) — добавляются автоматически. Т.е. поддержания обратного маппинга (от бинарника dll'ки к версии исходников) происходит без участия человеков типа «выпускающего».
    Глаза у меня добрые, но рубашка — смирительная!
    Re[2]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AlexNek  
    Дата: 19.11.11 14:07
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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


    AN>>Для MSVC, под виндами, С#, winforms, если что.

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

    A_A>ИМХО, однозначно только использовать подключение библиотек.

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

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

    То бишь сервер не у разработчика локально?
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[3]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AlexNek  
    Дата: 19.11.11 14:07
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

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


    A_A>>ИМХО, однозначно только использовать подключение библиотек.

    WH>хъ
    WH>Это все прекрасно делается с нормальными системами контроля версий
    Автор: Qbit86
    Дата: 19.11.11
    .

    WH>Поставь git или hg и будет тебе счастье.
    Увы, но система контроля версий не может менятся локально для команды. Многие процессы уже завязаны на конкретную систему.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[3]: Минусы
    От: AlexNek  
    Дата: 19.11.11 14:07
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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


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


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

    Q>
  • К задаче версионирования и публикации исходников добавляется задача версионирования и доставки разработчикам производных артефактов.
    Q>
  • Проще отлаживать, когда исходники рядышком.
    Да это мне тоже нравится, но с PDB вроде не должно быть отличий, исходники проекта и так всегда есть в наличии ( по крайней мере это одно из условий задачи).
    Отличие только в том, что происходит при связывании подпроектов.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
  • Re[4]: NuGet
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 14:13
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

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

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

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

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

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

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

    Клиенты сами решают юзать или нет новую версию.
    Re[4]: Минусы
    От: Qbit86 Кипр
    Дата: 19.11.11 14:13
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

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


    У тебя есть ссылка на dll'ку, методы в которой хочешь пройти пошагово. Но у тебя нет PDB. Значит его нужно отдельно собрать из исходников. Т.е. опять же решить проблему, какая версия исходников соответствовала той версии dll'ки, на которую у тебя ссылка.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[3]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 14:20
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

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

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

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

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

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

    В этом случае ссылки на библиотеки будут защитой от таких возможных последствий в сервере.
    Re[3]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 14:27
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

    A_A>>ИМХО, однозначно только использовать подключение библиотек.

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

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

    AN>То бишь сервер не у разработчика локально?
    Как получить сервер на клиенте — это уже другой вопрос

    Мы юзаем тоже NuGet — впечатления отличные, полет нормальный
    Re[5]: Плюсы
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 14:39
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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


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


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


    A_A>>Пример:

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

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


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


    Если на любые изменения в сервере делать ветки в СКВ и менять ссылки у клиентов на новый урл, то да — в данной ситуации различий нет.
    Re[5]: Минусы
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 15:00
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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


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


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


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

    А при релиз-билде все PDB будут отсутствовать.
    Re[4]: Модули
    От: AlexNek  
    Дата: 19.11.11 15:17
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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


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

    AN>>Есть только SVN.

    Q>Можно пристально посмотреть в сторону svn:externals.

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

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


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

    Так а "подключение" исходников по чейнджсету происходит также?
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[5]: NuGet
    От: AlexNek  
    Дата: 19.11.11 15:17
    Оценка:
    Здравствуйте, 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, когда готовы начать разрешать потенциально появившиеся конфликты из-за отсутствия обратной совместимости версий разрабатываемой переиспользуемой библиотеки.

    То бишь к бинаркам жестко привязаны исходники и наоброт?
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[6]: Плюсы
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 15:21
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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


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


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


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


    A_A>>>Пример:

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

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


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


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


    Кстати, в этом случае тебе придется делать отдельные билд-конфигурации на CI для каждой ветки.
    Визуально это будет очень неудобно, когда их будет много.
    Плюс придется тратить лишнее время на создание каждой конфигурации.
    Re[5]: Модули
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 15:31
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

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


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


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

    AN>>>Есть только SVN.

    Q>>Можно пристально посмотреть в сторону svn:externals.

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

    С такими аргументами нормальное руководство утверждает.
  • Re[5]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 15:43
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

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


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

    WH>Он много что позволяет, но все через задний проход с массой геморроя.

    A_A>>Система контроля версий здесь непричем.

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

    Я хочу сделать новую версию общей части для одного клиента:
    1)Коммичу код — запускаю билд с таргетом "Deploy" — автоматически создается новая версия NuGet пакета.
    По версии библиотеки (major.minor[.build[.revision]]) я всегда найду исходники и автора изменений.
    Подключаю новую версию библиотеки на клиенте.
    никаких бранчей и мерджев.
    Иду пить пиво
    Re[5]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 15:51
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

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


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

    WH>Он много что позволяет, но все через задний проход с массой геморроя.

    A_A>>Система контроля версий здесь непричем.

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

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

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

    А на вопрос версионирования и мерджев в SVN — это да, геморрой еще тот
    Re[6]: NuGet
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 16:01
    Оценка:
    Здравствуйте, 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>То бишь к бинаркам жестко привязаны исходники и наоброт?
    Да.
    Re[5]: NuGet
    От: AlexNek  
    Дата: 19.11.11 16:13
    Оценка:
    Здравствуйте, 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>Создается новая версия библиотеки -> она выкладывается куда-то в шару -> делается описание внесенных изменений -> идут уведомления клиентам о новой версии.
    Дело не идет о библиотеке и внешних клиентах, там все по другому. Разговор о команде разрабатывающей достаточно большой проект, скажем с полтинником подпроектов. И все проиходит именно на этапе разработки.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[5]: Минусы
    От: AlexNek  
    Дата: 19.11.11 16:13
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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


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


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

    PDB то будет идти с Длл-кой, но вот гарантировать совместимость исходников с ними, да проблема.
    И кстати, как сгенерить PDB без DLL-ки?
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[4]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AlexNek  
    Дата: 19.11.11 16:13
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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


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

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

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


    A_A>Пример:

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

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

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

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

    Значит голос за Длл-ки? А как быть тогда с совмещением ссылок на Длл-ки и проекты? Что делать разработчику именно этой Длл-ки в проекте? И что делать остальным когда исходники уже в репозитории, но бильд длл-ок еще не готов. Ждать пока не будет все готово и после все брать? А если в это же время закоммитились другие изменения, которые нужно пока избежать? (Допустим они исправили генерацию данных, и неправильные данные для теста уже получить просто невозможно) То есть нужно отслеживать два источника: исходники и бинарники, и к тому же учитывать иерархию бинарников.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[4]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AlexNek  
    Дата: 19.11.11 16:13
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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


    A_A>>>ИМХО, однозначно только использовать подключение библиотек.

    A_A>>>Назовем ради примера:
    A_A>>>общая часть — сервер,
    A_A>>>пользователи общей части — клиенты.
    AN>>То есть пример практически не связанного кода. Максимум — протоколы обмена, видимо.
    A_A>Отнюдь не только. Библиотеки .NET Framework — это связанный код с твоими проектами или нет?
    А у меня есть исходники .NET Framework в проекте?
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[6]: Модули
    От: AlexNek  
    Дата: 19.11.11 16:24
    Оценка:
    Здравствуйте, 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ообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
  • Re[7]: NuGet
    От: AlexNek  
    Дата: 19.11.11 16:28
    Оценка:
    Здравствуйте, 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>Да. перемешивать нельзя — бардак будет еще тот.
    А как тогда работать разработчику Длл-ки? Причем один разработчик часто отвечает за более чем одну Длл-ку?
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[6]: Как лучше подключать подпроекты - DLL или исходники ч
    От: WolfHound  
    Дата: 19.11.11 16:41
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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

    A_A>поэтому вариант с подключением сорцов из транка как SVN:externals является нормальным.
    Подключения без фиксирования ревизии не может быть нормальным.
    Ибо ты потом не сможешь вытащить ту же версию исходников, с которой собирал.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[6]: NuGet
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 16:45
    Оценка:
    Здравствуйте, 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 проектами — тогда бы овчинка выделки не стоила и юзание сорцов по ссылке было удобнее.
    Re[5]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 17:02
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

    AN>Значит голос за Длл-ки?

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

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

    Тут на помощь конечно приходит CI, NuGet и хорошее покрытие тестами общего фцнкйионала.
    Re[5]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 17:04
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

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


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


    A_A>>>>ИМХО, однозначно только использовать подключение библиотек.

    A_A>>>>Назовем ради примера:
    A_A>>>>общая часть — сервер,
    A_A>>>>пользователи общей части — клиенты.
    AN>>>То есть пример практически не связанного кода. Максимум — протоколы обмена, видимо.
    A_A>>Отнюдь не только. Библиотеки .NET Framework — это связанный код с твоими проектами или нет?
    AN>А у меня есть исходники .NET Framework в проекте?
    Догадываюсь, что нету.
    Так значит юзание библиотек является достаточным.
    Re[7]: Модули
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 17:14
    Оценка:
    Здравствуйте, 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>А кто, сколько времени и на что будет перестраивать все остальное?
    делаете предварительные исследования в свободное от работы время(это на самом деле вам же, разработчикам, нужно )
    закидываете ссылками, что это можно сделать
    берете время
    делаете
  • Re[8]: NuGet
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 17:22
    Оценка:
    Здравствуйте, 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.
    Re[7]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 17:34
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

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


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

    WH>Любая распределенная.
    давайте уточним, что мы имеем ввиду одно и тоже.

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

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

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

    A_A>>Я хочу сделать новую версию общей части для одного клиента:

    WH>В это время другой программист захотел сделать тоже самое.
    WH>
    В обоих случаях топикстартера это возможно.
    Re[7]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 17:37
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

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


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

    A_A>>поэтому вариант с подключением сорцов из транка как SVN:externals является нормальным.
    WH>Подключения без фиксирования ревизии не может быть нормальным.
    WH>Ибо ты потом не сможешь вытащить ту же версию исходников, с которой собирал.
    дык, я солидарен, что если требуется версионирование общей части, то подключение исходников как
    SVN:externals несет в себе больше возможных неприятностей, чем юзание библиотек
    Re[7]: Плюсы
    От: Qbit86 Кипр
    Дата: 19.11.11 18:04
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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


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

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


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

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


    Нет. Есть конфигурация для клиента и сервера.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[6]: Pdb
    От: Qbit86 Кипр
    Дата: 19.11.11 18:13
    Оценка:
    Здравствуйте, 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-файла, они связывают символы с исходниками разработчика, а не моим комплектом исходников.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[8]: Как лучше подключать подпроекты - DLL или исходники ч
    От: WolfHound  
    Дата: 19.11.11 18:13
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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

    А версионник у нас чем занимается?

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

    А версионник нам на что? Они прекрасно справляются с вытаскиванием другой равизии.

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

    Зачем запретить?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[6]: Pdb
    От: Qbit86 Кипр
    Дата: 19.11.11 18:14
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

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

    AN>И кстати, как сгенерить PDB без DLL-ки?

    http://www.rsdn.ru/forum/philosophy/4503615.aspx
    Автор: Qbit86
    Дата: 19.11.11
    Глаза у меня добрые, но рубашка — смирительная!
    Re[8]: Плюсы
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 18:15
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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


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


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


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


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


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


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


    Тогда разницы нет, за исключением случая, что девелопер ВысокоуровневойОбёртки может внести изменения и закоммитить код БиблиотекиПримитивов.
    Re[7]: Pdb
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 18:25
    Оценка:
    Здравствуйте, 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 дает нам возможность узнать номера строк в файлах при исключениях
    версию исходников мы узнаем из версии пакета

    Это конечно мало поможет, если версия будет очень старой, но если версия последняя — можно пофиксить, как говорится "не отходя от кассы исключения"
    Re[9]: Плюсы
    От: Qbit86 Кипр
    Дата: 19.11.11 18:25
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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


    Ещё может легко и непринуждённо по ней отлаживаться. Найти какой-нибудь мелкий баг, не отходя от кассы его исправить.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[9]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 18:27
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

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

    WH>Зачем запретить?
    потому что они джуниоры и не имеют еще достаточной квалификации, чтобы менять критически важную для проекта часть
    Re[10]: Плюсы
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 18:29
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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


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


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


    тут я не спорю, этот минус я изначально указал
    Re[8]: Pdb
    От: Qbit86 Кипр
    Дата: 19.11.11 18:37
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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


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

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


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

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


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

    Т.е. принципиальная возможность идентифицировать версию исходников по бинарнику быть должна, но постоянно пользоваться таким способом — удовольствие сомнительное.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[11]: Плюсы
    От: Qbit86 Кипр
    Дата: 19.11.11 18:44
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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


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

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

    Кроме того, нужно написать ПользовательскоеПриложение, которое использует всю мощь и величие нашей БиблиотекиПримитивов, причём заказчику предоставляется исходный код этого ПользовательскогоПриложения в качестве демонстрации использования API нашей БиблиотекиПримитивов.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[9]: Pdb
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 18:45
    Оценка:
    Здравствуйте, 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, поэтому номера ревизии достаточно.
    А разработка общей части идет всегда в транке.
    Re[10]: Как лучше подключать подпроекты - DLL или исходники
    От: WolfHound  
    Дата: 19.11.11 18:53
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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

    Ты с распределенными версионниками вообще работал?
    Они для того и созданы чтобы изменения без изучения ответственными лицами не проходили в основной репозиторий.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[12]: Плюсы
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 18:54
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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


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


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

    +1

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

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

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

    имхо, заказчику вообще пофиг как мы там внутри юзаем — со ссылками на исходники или библиотеки
    ему важно, чтобы функционал был готов в нужный для него срок
    вот тут и нужно разработчикам решать как организовать такие сценарии
    Re[11]: Как лучше подключать подпроекты - DLL или исходники
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 19:01
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

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


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

    WH>Ты с распределенными версионниками вообще работал?
    Вообще-то нет
    WH>Они для того и созданы чтобы изменения без изучения ответственными лицами не проходили в основной репозиторий.
    Процесс коде-ревью встроенный в СКВ?
    Прикольно.
    Тогда распределенные СКВ рулят.
    Re[13]: ДемонстрационныйПроект
    От: Qbit86 Кипр
    Дата: 19.11.11 19:02
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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


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

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

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

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

    Т.е. мы, разрабатывая ДемонстрационныйПроект входим в роль заказчика и пользуемся только теми средствами, которые будут ему доступны. Ему не будет доступна опция «сослаться на проект» — у него не будет проекта, только бинарник.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[14]: ДемонстрационныйПроект
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 19:07
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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


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


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


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

    Еще плюс бинарников в том, что у нас в солюшене будет на один проект меньше
    Re[4]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 19:14
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

    Z>>>А оно вам надо? И зачем вообще тратить время на загрузки "актуальных версий"?

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

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


    А если разработчики работают в одной компании, но в разных командах(допустим даже под одним проджект менеджером).
    И тут разработчик вносит изменения в общий код, который принадлежит другой команде(которая уже выделила свою архитектуру этого проекта)
    и эти изменения не вписываются аж никак в ихнюю архитектуру.
    они потом видят это и говорят проджект менеджеру, что внесли изменения, которые испортили текущую архитектуру и т.п.
    Тут мы на ровном месте получаем конфликт, которого можем избежать если изменения будут вносить только авторы системы
    Re[5]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 19.11.11 19:39
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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


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


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

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


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

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


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

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

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

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

    Ты не путай: "могут вносить" и "будут вносить". Одно из другого, в общем, не следует. Это прямая задача управленцев — объяснить, что в чужие исходники лазить не надо. Смотреть можно, менять — нет. Зато такой подход снимает кучу проблем по части выяснения источника ошибок.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[6]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 19:56
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

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


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

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

    Вероятность такая отсутствует в случае ссылок на бинарники.
    Re: Как лучше подключать подпроекты - DLL или исходники чере
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 19.11.11 20:01
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

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


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

    А всякие параноидальные "защиты" — это всё детсад, напакостить при желании можно где угодно. Скажем, кто-то даст кому-то по дружбе доступ к репозиторию... Короче, всё это разговоры в пользу бедных — организационные задачи техничесиким средствами не решаются.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[5]: Авторизация
    От: Qbit86 Кипр
    Дата: 19.11.11 20:04
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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


    Если изменение должны вносить только авторы системы, то у посторонних должны быть права максимум на чтение.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[13]: Как лучше подключать подпроекты - DLL или исходники
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 20:12
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

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


    A_A>>Процесс коде-ревью встроенный в СКВ?

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

    А кстати, если у SVN репзитория менять svn:externals, то хранится ли в истории эта информация?
    Re[7]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 19.11.11 20:13
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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


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


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

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


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

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

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

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

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

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

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

    — Скачать все нужные исходники в одном солюшене;
    — Собрать все нужные бинари;
    — Отделить нужные тебе проекты в обособленный солюшен — и всё, ничего ты случайно не поменяешь.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[8]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 20:29
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

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

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

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


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

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

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

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

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


    ГВ>- Скачать все нужные исходники в одном солюшене;

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

    а как будем качать исходники различных версий?
    паковать в пакет с бинарями?
    Re[2]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 20:31
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

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


    кстати в логах то будет аккаунт именно того кто даст доступ по дружбе,
    так что тут уж дружба-дружбой а аккаунты врознь
    Re[6]: Авторизация
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 20:34
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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


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


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


    Да, согласен.
    Re[14]: Как лучше подключать подпроекты - DLL или исходники
    От: hardcase Пират http://nemerle.org
    Дата: 19.11.11 20:35
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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


    Естественно.
    /* иЗвиНите зА неРовнЫй поЧерК */
    Re[15]: Как лучше подключать подпроекты - DLL или исходники
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 20:37
    Оценка:
    Здравствуйте, hardcase, Вы писали:

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


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


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


    Так тогда чем распределенные СКВ в данном случае лучше серверных?
    Re[6]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 19.11.11 20:41
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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

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

    ClearCase хорошо с бранчами умеет работать. Например, позволяет собрать бранч из отдельных файлов любых веток и версий. Она вообще много чего позволяет. Но денег стоит ($4600/user).
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[2]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 20:46
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

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


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

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

    Является ли эта защита параноидальной?
    Re[9]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 19.11.11 20:50
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

    A_A>Пример:

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

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

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

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

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

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

    A_A>ну, результаты уже мы знаем

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

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

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

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

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


    ГВ>>- Скачать все нужные исходники в одном солюшене;

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

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

    A_A>паковать в пакет с бинарями?

    Ответ зависит от того, как выглядит ваше дерево (деревья) проектов. В принципе, это решается скриптами и бранчами.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[3]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 19.11.11 20:51
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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


    A_A>кстати в логах то будет аккаунт именно того кто даст доступ по дружбе,

    A_A>так что тут уж дружба-дружбой а аккаунты врознь

    Ага-ага.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[16]: Как лучше подключать подпроекты - DLL или исходники
    От: hardcase Пират http://nemerle.org
    Дата: 19.11.11 20:53
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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


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


    Тем что они распределенные. В git-е кроме submodule (аналог svn:externals) есть subtree.
    /* иЗвиНите зА неРовнЫй поЧерК */
    Re[10]: Как лучше подключать подпроекты - DLL или исходники
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 20:58
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

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


    A_A>>Пример:

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

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


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

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

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


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

    A_A>>ну, результаты уже мы знаем

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


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

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

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


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

    А в случае с бинарями новичок придет к лиду, что бага в такой-то библиотеке и чего дальше делать-то мол.
    И вопрос будет решаться теми, кто несет ответственность за эти модули со 100-процентной вероятностью.
    Re[11]: Как лучше подключать подпроекты - DLL или исходники
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 19.11.11 21:02
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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


    А как он узнает, что бага в такой-то библиотеке а не в его коде?
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[17]: Как лучше подключать подпроекты - DLL или исходники
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 21:03
    Оценка:
    Здравствуйте, hardcase, Вы писали:

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


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


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


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


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

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

    со все этим SVN справляется, в чем геморрой-то будет?
    Re[4]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 21:12
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

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


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

    A_A>>Кстати вот на перекрестках есть светофоры — они предназначены разруливать организационную задачу — ПДД

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


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

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


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


    A_A>>[...]

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

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


    имхо, аналогия очевидна — избавляемся от рисков получения потенциальных проблем в редких случаях
    Re[12]: Как лучше подключать подпроекты - DLL или исходники
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 21:16
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

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


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


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


    К примеру при вызове метода поймает NotImplementedException
    Re[3]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Andrii_Avramenko Украина  
    Дата: 19.11.11 21:20
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

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


    A_A>>ИМХО, однозначно только использовать подключение библиотек.

    WH>хъ
    WH>Это все прекрасно делается с нормальными системами контроля версий
    Автор: Qbit86
    Дата: 19.11.11
    .

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

    Ведь то же самое можно сделать и на SVN.
    Чем распределенные СКВ в данном случае лучше?
    Re[5]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 19.11.11 21:56
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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


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


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

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


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

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

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


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

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

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

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

    Разве что очень поверхностная. На самом деле тут вопрос в цене. ИМХО, всяко проще объяснить людям, что не надо лазить в чужой код (читай, рассказать о правилах перестроения), чем выдумывать сложные инструментальные подходы (читай, строить отдельный путепровод для каждого маршрута из всех точек А во все точки Б).
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[13]: Как лучше подключать подпроекты - DLL или исходники
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 20.11.11 00:16
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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

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

    А как он будет такую проблему решать? Неужели кинется дописывать код?
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re: Как лучше подключать подпроекты - DLL или исходники чере
    От: Jiteco  
    Дата: 20.11.11 01:20
    Оценка:
    ч
    AN>Для MSVC, под виндами, С#, winforms, если что.
    AN>Временами на работе возникают дискуссии, что подключать лучше в солюшин как внешние ссылки при наличии исходников — DLL-ки или проекты.
    AN>Понятно что абсолютно однозначного ответа нет, зависит от конкретной ситуации. Допустим, когда исходники стабильные и практически не меняются, либо от кого-то другого, то видимо DLL-ки с PDB (и отдельными исходниками для отладки) лучше. По крайней мере, нет никакой возможности изменить непреднамеренно код.

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

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

    В каждом случае по разному
    ... << RSDN@Home 1.2.0 alpha 5 rev. 1537>>
    Screen Capture Software
    Re[7]: NuGet
    От: AlexNek  
    Дата: 20.11.11 11:53
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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


    A_A>>>1) Если нет человека с такой должностью — нужно завести должность и взять человека

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

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

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

    A_A>Вот именно в этом случае пригодится юзание библиотек.

    A_A>Если был бы простенький проект на 2-3 человека с 10-15 проектами — тогда бы овчинка выделки не стоила и юзание сорцов по ссылке было удобнее.
    Честно говоря, не вижу зависимости удобства от количества, если не учитывать какие то определенные параметры, например время компиляции (в данном случаем им можно пренебречь). То бишь нужно определится с критериями.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[6]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AlexNek  
    Дата: 20.11.11 11:53
    Оценка:
    Здравствуйте, 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) Следите только за изменениями в функционале и версиями — на сорцы вам пофиг
    на сорцвы не пофиг, откуда бильдить локальные версии на время правки?
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[6]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AlexNek  
    Дата: 20.11.11 11:53
    Оценка:
    Здравствуйте, 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>Так значит юзание библиотек является достаточным.
    Это для случая когда библиотека является окончанием иерархии, а чужая библиотека обычно этому требования подчиняется. Иначе говоря, у нас нет исходников базовых классов библиотеки или каких либо ее частей, которые нам нужно изменять. Абсолютно любая часть библиотеки будет всего конечным листом для нашего проекта.
    Именно только этом случае это будет достаточным.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[8]: Модули
    От: AlexNek  
    Дата: 20.11.11 11:53
    Оценка:
    Здравствуйте, 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ообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
  • Re[9]: NuGet
    От: AlexNek  
    Дата: 20.11.11 11:53
    Оценка:
    Здравствуйте, 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>Просто надо больше комунницировать, чтобы о таких изменениях все были в курсе.
    А если было сказано об изменениях, но допустим забыли, что то сделать, что привело к "рассогласованию" исходников с бинарниками.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[7]: Pdb
    От: AlexNek  
    Дата: 20.11.11 11:53
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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


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

    AN>>И кстати, как сгенерить PDB без DLL-ки?

    Q>http://www.rsdn.ru/forum/philosophy/4503615.aspx
    Автор: Qbit86
    Дата: 19.11.11

    И где же там ответ на поставленный вопрос?
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[4]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AlexNek  
    Дата: 20.11.11 11:53
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

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


    Z>>>А оно вам надо? И зачем вообще тратить время на загрузки "актуальных версий"?

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

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

    Речь идет о непреднамеренном изменении, причем в уже протестированной части (и "закрытой") части. А исходники и так доступны всем при двух вариантах. Только при подключении Длл-ок нужно целенаправленно лезть в иходники, а при подключенных исходниках это может сделать и прога рефакторига.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[2]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AlexNek  
    Дата: 20.11.11 11:53
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

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


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


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


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


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

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

    Репозиторий и так один, а вот забыть еще в одном месте кнопочку нажать, довольно просто.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[2]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AlexNek  
    Дата: 20.11.11 11:53
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

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


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


    ГВ>Задача-максимум: иметь возможность полностью пересобрать все проекты на любой машине разработчика.

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

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

    Это уже вопрос оптимизации.
    ГВ>А если сборка всех ваших исходников укладывается в час-два (сторонние библиотеки сейчас не считаем), то уместно иметь полную копию всех исходных текстов.
    Я бы сформулировал следующее. Если проект находится в конечном листе иерарахии проектов, то с целью экономии времени, лучше поключать Длл-ки.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[2]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AlexNek  
    Дата: 20.11.11 11:53
    Оценка:
    Здравствуйте, Jiteco, Вы писали:

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

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

    Вроде это было написано в самом начале. А какие могут быть случаи, что нужно учитывать при выборе, что мы приобретаем, что тереям при выборе того или иного решения и т.п.
    По крайней мере, мне кажется, что из обсуждения мне уже удалось выловить общие принципы выбора того или иного решения.
    Теперь осталось их проверить на "вшивость".
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[8]: Pdb
    От: Qbit86 Кипр
    Дата: 20.11.11 15:58
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

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


    Там задаётся встречный вопрос — зачем поставлять pdb с бинарниками?
    Глаза у меня добрые, но рубашка — смирительная!
    Re[9]: Pdb
    От: AlexNek  
    Дата: 20.11.11 16:29
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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


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


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

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

    А то что пути конкретны — это в большей степени наплевать -Файлы баз данных программ
    Ну и к тому же в команде все относительные пути одинаковые, а бывает даже и абсолютные также одинаковы.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[6]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 20.11.11 18:09
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

    AN>>А у меня есть исходники .NET Framework в проекте?

    A_A>Догадываюсь, что нету.

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

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


    Две ноги тоже достаточны для перемещения.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[8]: NuGet
    От: Andrii_Avramenko Украина  
    Дата: 20.11.11 20:36
    Оценка:
    Здравствуйте, 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 и искать в истории своего проекта, какую же версию общего функционала он юзал
    хотя, вероятность в такой нужде конечно невысокая
    Re[7]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Andrii_Avramenko Украина  
    Дата: 20.11.11 21:02
    Оценка:
    Здравствуйте, 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>на сорцвы не пофиг, откуда бильдить локальные версии на время правки?
    насколько я понял, длл-ка принадлежит "нашей" команде, так что этот пункт уже не имеет значение
    Re[9]: Модули
    От: Andrii_Avramenko Украина  
    Дата: 20.11.11 21:16
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

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

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

    Это как риски покупать или нет новый более мощный компьютер — ты ж его еще не юзал, а только слышал\читал об его возможностях.
    Re[10]: NuGet
    От: Andrii_Avramenko Украина  
    Дата: 20.11.11 21:25
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

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

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

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


    AN>>>А как тогда работать разработчику Длл-ки? Причем один разработчик часто отвечает за более чем одну Длл-ку?

    A_A>>А в чем проблема-то?
    A_A>>Просто надо больше комунницировать, чтобы о таких изменениях все были в курсе.
    AN>А если было сказано об изменениях, но допустим забыли, что то сделать, что привело к "рассогласованию" исходников с бинарниками.
    Автоматизация без участия человека не допустит рассогласования исходников с бинарниками.
    Re[7]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Andrii_Avramenko Украина  
    Дата: 20.11.11 21:34
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

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


    AN>>>А у меня есть исходники .NET Framework в проекте?

    A_A>>Догадываюсь, что нету.

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


    А в чем профит от отладки по исходникам .NET Framework?
    Пересборка его все равно не имеет смысла.
    Для меня например важно, что функционал какой-то библиотеки выполняет заявленные требования.
    Если не выполняет, то по какой причине:
  • если я передаю некорректные входные параметры, то какие именно и какие границы корректности
  • если по вине библиотеки, то это уже не моя проблема
    Во всех случаях я не вижу практического смысла в наличии исходников.
  • Re[14]: Как лучше подключать подпроекты - DLL или исходники
    От: Andrii_Avramenko Украина  
    Дата: 20.11.11 21:45
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

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


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

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

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


    Это примерчик я привел смеху ради конечно

    Более реальный, когда ловит IndexOutOfRangeException
    Re[6]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Andrii_Avramenko Украина  
    Дата: 20.11.11 22:36
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

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


    Плохое я сделал ТЗ в начале, не детализированное
    Давайте уточним.
    Заказчик: министр внутренних дел
    Бизнес требование: организовать гарантированное безопасное двухстороннее автомобильное движение на дороге
    Имеем: на дороге отсутствуют какие-нибудь знаки, разметка и т.п., зато присутствуют нарушения двухстороннего автомобильного движения.
    Организационное решение:
    1) Наносим одинарную разделительную полосу — обучаем всех водителей, что пересекать ее низзя ни при каких условиях.
    Рапортуем министру, что теперь двухстороннее автомобильное движение на дороге будет безопасным.
    Идем пить пиво с министром за клево сделанную работу
    Министр вызывает нас на ковер и негодует — нарушения остались.

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

    3)Устанавливаем знаки(ограничение максимальной скорости, запрет обгона) — обучаем всех водителей, что нарушать их низзя ни при каких условиях.
    Рапортуем министру, что теперь-то уж верняк двухстороннее автомобильное движение на дороге будет безопасным.
    Идем пить пиво(без министра — ну его, че-то он какой-то нервный последнее время) за клево сделанную работу
    Министр вызывает нас на ковер и опять негодует — нарушения остались.
    Да иди ты [направление поскипано] со своей дорогой, думаем мы.
    Сваливаем в министерство юстиции.

    4) Пришла другая команда и забацала путепровод.
    Другая команда идет пить пиво с министром за клево сделанную работу

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

    Имхо, разница в цене очевидна, если нужна гарантия.
    Да и инструментальный подход попроще буит, а главное — гарантирует результат.
    Re[7]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 20.11.11 23:15
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

    [...]

    Я так понял, что ты хотел проиллюстрировать известную поговорку про две российские беды, нет?
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[15]: Как лучше подключать подпроекты - DLL или исходники
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 20.11.11 23:18
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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

    [...]
    A_A>Более реальный, когда ловит IndexOutOfRangeException

    Это может указывать и на ошибку в своём коде.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[5]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 20.11.11 23:21
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

    Z>>>>А оно вам надо? И зачем вообще тратить время на загрузки "актуальных версий"?

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

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

    Ещё тут высказывали мысль, что можно часть репозитория открывать только на чтение — можно попробовать поиграть с таким подходом.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[3]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 20.11.11 23:27
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

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


    ГВ>>Задача-максимум: иметь возможность полностью пересобрать все проекты на любой машине разработчика.

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

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

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

    AN>Это уже вопрос оптимизации.

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

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

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

    Да экономия времени-то не ахти какая большая, прямо скажем. Меня смущают в подключении только DLL возможные конфликты платформ (x86, x64, AnyCPU, etc.) и конфигураций (Debug, Release). Второе в меньшей степени, конечно.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[3]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Ziaw Россия  
    Дата: 21.11.11 08:14
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

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


    Пользы нет, вред есть. Какие еще аргументы нужны?
    Re[4]: Модули
    От: SleepyDrago Украина  
    Дата: 21.11.11 09:06
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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


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

    AN>>Есть только SVN.

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


    Я имел дело с 5ти уровневой структурой библиотек с бинарниками в externals для плюсов. Больше не буду и такое проскочит только через мой труп. Там где я сейчас, есть один проект вынесенный в бинарную зависимость в перфорсе. Я прекрасно понимаю почему (его сложно собирать и лицензия там под сомнением), но он создает в работе серьезные проблемы. По поводу свн еще могу добавить что после административных изменений на сервере номера ревизий могут и поменяться и весь этот карточный домик сложится в один момент.
    Re[5]: 5-уровневая структура
    От: Qbit86 Кипр
    Дата: 21.11.11 09:32
    Оценка:
    Здравствуйте, SleepyDrago, Вы писали:

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


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


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

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


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

    See also: Use a thin shell repository to manage your subrepositories.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[8]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 21.11.11 09:57
    Оценка:
    Здравствуйте, 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>>
  • AVK Blog
    Re[9]: Две российские беды
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 21.11.11 09:57
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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


    Она не то чтобы себя изжила, она с самого начала не годилась. Как и любая другая аналогия.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[4]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Andrii_Avramenko Украина  
    Дата: 21.11.11 18:48
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

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

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

    ГВ>Да экономия времени-то не ахти какая большая, прямо скажем.

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

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


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

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

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


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


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

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


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


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


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

    Согласен.
    Скажу только, что всякие локальные версии должны отсутствовать в принципе.
    Нет их и не нужны они.
    Если все же в них появляется необходимость — решать проблемы в процессе распределения задач с условиями минимизации пересечения разработчиков над одними функциями в единицу времени.
    Re[17]: NullReferenceException
    От: Andrii_Avramenko Украина  
    Дата: 21.11.11 19:27
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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


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


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


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

    Ну, о минусах уже известно. Расскажу за плюсы, которые мы для себя тогда определили.
  • Всегда ясно видно, что в проекте есть ссылка на нестандартную(не из .NET Framework) либу. Все нестандартные либы качаются с помощью батника.
    Т.е. мне не нужно лезть ни в какие svn-свойства папки и смотреть, откуда же они здесь появляются после апдейта.
  • Нам нужно отвязаться от внешних зависимостей от конретного модуля в текущей разработке. Для этого нам нужно версионировать внешние модули.
    Решили в пользу юзания либ, чем ссылание на различные версии ревизий( никому не нравится лазить по этим номерам ревизий и переключать их,
    да и ошибиться там можно).
  • Все задачи делаем согласно тикетам в джире. Без тикета работа не ведется(бывает конечно, особенно в горячих баг-фиксах, но редко).
    Соответственно, в случае изменения либы заводится новый тикет на работу в либе, и зачастую работа сразу параллелится,
    чтобы закрыть таску по проекту в срок.
    Т.о. мы сами себя застраховали от возможных горячих баг-фиксов "на скорую руку в конце рабочего дня" и стараемся решать проблемы с системным подходом.
    Уже где-то месяца полтора так работаем — ни у кого не возникло желание заюзать svn:externals.
  • Re[9]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Andrii_Avramenko Украина  
    Дата: 21.11.11 19:36
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

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

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

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


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

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

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


    И каким образом ты пользуешься результатами устранения багов в исходниках .Net Framework?
  • Re[4]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AlexNek  
    Дата: 21.11.11 19:45
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

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


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

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

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

    Во первых, в репо не один проект. Во вторых, в ветке проекта, не только исходники, но и все сопутствующее.
    В третьих, скорость. В четвертых, все слепо коммитить запрещено. Ну и в основном, работа происходит через плагин к студии. Если брать с роота обновления, то будет длиться довольно долгое время.
    Но дело ведь не в чтении, но и в записи.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[9]: NuGet
    От: AlexNek  
    Дата: 21.11.11 19:45
    Оценка:
    Здравствуйте, 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>хотя, вероятность в такой нужде конечно невысокая
    Я бы сказал, довольно низкая. Пока вижу только вариант для какого либо специального теста. Хотя как критерий пожалуй подойдет.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[8]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AlexNek  
    Дата: 21.11.11 19:45
    Оценка:
    Здравствуйте, 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>Один обновил длл-ку -> сообщил нуждающимся номер версии и суть обновлений -> они скачали и юзают.
    Для вариантов когда нужно брать не все.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[10]: Модули
    От: AlexNek  
    Дата: 21.11.11 19:45
    Оценка:
    Здравствуйте, 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>Это как риски покупать или нет новый более мощный компьютер — ты ж его еще не юзал, а только слышал\читал об его возможностях.
    Можно было и подискутировать о правильности данного примера, но ну его.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[11]: NuGet
    От: AlexNek  
    Дата: 21.11.11 19:45
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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


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

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

    Видимо Вы не так поняли, что я имел в виду.
    Допустим раньше параметр не проверялся на ноль, а теперь сделали. Но вылет все равно проиходит по нулю (Длл-ка не обновилась). Смотрим исходники все нормально, не может там такого быть.
    Ну а все всегда не перекроешь.
    AN>>>>>>>>А будет ли обеспечено, что исходники всех разработчиков будут точно сообтветствовать бинарникам.

    AN>>>>А как тогда работать разработчику Длл-ки? Причем один разработчик часто отвечает за более чем одну Длл-ку?

    A_A>>>А в чем проблема-то?
    A_A>>>Просто надо больше комунницировать, чтобы о таких изменениях все были в курсе.
    AN>>А если было сказано об изменениях, но допустим забыли, что то сделать, что привело к "рассогласованию" исходников с бинарниками.
    A_A>Автоматизация без участия человека не допустит рассогласования исходников с бинарниками.
    Это будет только в том случае когда прогу также роботы писать будут, а за ними будут другие роботы наблюдать. А так можно почти всегда найти ситуации в которых механизм даст сбой.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[6]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AlexNek  
    Дата: 21.11.11 19:45
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

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


    Z>>>>>А оно вам надо? И зачем вообще тратить время на загрузки "актуальных версий"?

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

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

    Случайно изменить исходники можно многими методами.

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

    Это же кто и как будет это все администрировать.
    Пока вот всего один единственный проект разрешили редактировать только экслюзивно и то часто возникают проблемы
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[4]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AlexNek  
    Дата: 21.11.11 19:45
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

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


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


    ГВ>>>Задача-максимум: иметь возможность полностью пересобрать все проекты на любой машине разработчика.

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

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

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

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

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

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

    Разработка проиходит на одной заранее определенной платформе.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[4]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AlexNek  
    Дата: 21.11.11 19:45
    Оценка:
    Здравствуйте, Ziaw, Вы писали:

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


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


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

    Пользу можно не заметить, а вред преувеличивать.
    Кстати, о каком варианте речь?
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[4]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AlexNek  
    Дата: 21.11.11 19:45
    Оценка:
    Здравствуйте, Ziaw, Вы писали:

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


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


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

    Слово "Автор" не зря было взято в кавычки. Можно сказать текущий отвественный(-ные) за модификацию данной части кода.

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


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

    Это и так всем известно. Речь идет о непреднамеренном изменении.

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

    Как говорили, автомат вначале распространит первое исправление, затем второе.

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


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

    Как сделать без локальной версии?
    Загрузился набор Длл-ок теперь требуется делать исправление в одной из них. Вначале то правится нужно локально, то есть собирать ее из исходников. Значит все исходники должны точно соотвествовать всем Длл-кам. И видимо в 99% случаев это будет именно так.
    Z>Версия должна быть одна и любая ревизия должна собираться ровно так же как она собиралась на машине разработчика который ее создал, прогнал тесты и подписался под комитом. Любые другие способы ведут к неиллюзорным граблям.

    Z>Бинарные ссылки допустимы только для внешних, по отношению к проекту зависимостей.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[5]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AlexNek  
    Дата: 21.11.11 19:49
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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


    A_A>Мы, собственно, всегда под AnyCPU в Release и собираем — зачем иначе?

    Попробуйте установить прогу на 64 битную ось.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[5]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Andrii_Avramenko Украина  
    Дата: 21.11.11 19:52
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

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


    У нас есть команда из трех человек, которая пишет обертку над супер важными для бизнеса библиотеками коре-аналитики.
    Так они этих библиотек в глаза никогда не видели.
    Пишут по интерфейсам, которые по документации читают
    Re[6]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Andrii_Avramenko Украина  
    Дата: 21.11.11 19:54
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

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


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


    A_A>>Мы, собственно, всегда под AnyCPU в Release и собираем — зачем иначе?

    AN>Попробуйте установить прогу на 64 битную ось.
    Так сервера на продакшене все 64-битные. Ничего не пересобирается.
    Оно ж AnyCpu. В чем проблема?
    Re[10]: Как лучше подключать подпроекты - DLL или исходники
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 21.11.11 19:58
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

    A_A>Мне здесь помогает документация


    Документация неполна, в отличие от исходников. Свеженький пример — попробуй найти в документации что нибудь по поводу того, какие в ремоутинге хидеры проходят уже в реальный HTTP запрос или ответ, и по какому алгоритму отфильтровываются те, что туда не проходят. Или как в реквесте на сервере формируется хидер __Uri.

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


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

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

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

    Вариантов избежания ситуации много:
    1) Понять, что ошибка таки была не в фреймворке.
    2) Понять, как подобрать входные параметры, чтобы ошибочная ситуация не возникала
    3) Понять, какой кусок фреймворка надо переписать, чтобы обойти ситуацию без исправлений фреймворка
    4) Воспроизвести багу минимальным семплом, закинуть на коннект. Пнуть нужных людей в Редмонде, получить на руки хотфикс.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[18]: Батники
    От: Qbit86 Кипр
    Дата: 21.11.11 20:00
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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


    Зачем батники, чем MsBuild не устроил?
    Глаза у меня добрые, но рубашка — смирительная!
    Re[12]: NuGet
    От: Andrii_Avramenko Украина  
    Дата: 21.11.11 20:09
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

    AN>Допустим раньше параметр не проверялся на ноль, а теперь сделали. Но вылет все равно проиходит по нулю (Длл-ка не обновилась). Смотрим исходники все нормально, AN>не может там такого быть.

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

    A_A>>Автоматизация без участия человека не допустит рассогласования исходников с бинарниками.

    AN>Это будет только в том случае когда прогу также роботы писать будут, а за ними будут другие роботы наблюдать. А так можно почти всегда найти ситуации в которых механизм даст сбой.
    Давайте расскажу поподробнее за этот механизм.
    При создании новой версии либы, разработчик делает билд на CI с таргетом "Deploy". Если этот проект не поддерживает такой таргет
    (т.е. не Database project or Web project etc.) тогда мы получим фейл билда и узнаем сразу.
    Если процесс версионирования NuGet настироен неправильно -> получим фейл билда и узнаем сразу.
    Итак, билд прошел успешно.
    Если мы укажем несуществующую версию либы(т.е. кот орой нет физически в фиде NuGet) -> получим фейл апдейта батника NuGet и узнаем чуть по-позже.
    имхо, вероятность сбоя невелика.
    Re[11]: Модули
    От: Andrii_Avramenko Украина  
    Дата: 21.11.11 20:35
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

    A_A>>Делаете пилотные проекты(лучше скопировать текущие самые сложные, с наибольшим количеством зависимостей) — на них играетесь

    AN>Кто даст время, деньги, ресурсы?
    Заказчик конечно.
    А вот твоя задача — объяснить ему, что эти затраты для него окупятся Плюс он еще и заработает на этом в ближайшем будущем.
    Насчет ближайшего будущего лучше поделикатней, конечно, без гарантий.
    A_A>>Потом постепенно переводите текущие на новую систему.
    A_A>>Риски всегда есть. Чтобы о них узнать заранее нужно проводить ресерч.
    AN>Прототип можно и за час сделать, а вот уже довести его до ума и подкрутить все мелочи — это уже время.
    A_A>>А по поводу переходить или нет — выписываешь в список плюсы и минусы существующей системы и новой(насколько возможно собрать информацию)
    A_A>>и будет ясно.
    AN>Можно долго и нудно все выписывать и подсчитывать, но вот как быть с неким правилом — "не трогай рабочую систему".
    Оо, это самое вкусное.
    На прошлой конторе заказчики были из Израиля — все решения о не то что переводе на что-то более удобное в разработке,
    а о банальном рефакторинге в легаси-коде(который находится в активной разработке еще), проходили с жуткими боями в виде закидывания аргументами.
    После замеров времени выполнения трех(самых веселых) методов сервисов бизнес-логики и выкладывания этого всего дела в виде красивых графиков,
    моя рекомендация по переводу проектов с .NET 2.0 на .NET 4.0 была воспринята без единого спора. (А те проекты были на 2.0 с 2005 года).
    Разница во времени выполнения была в 7.5 раз В старом коде были абсолютно неиспользуемые(т.е. тупо холостые) вызовы методов со стек-трейсом до
    12 методов, которые даже в базу лезли. Но менеджерам я об этом естесственно не говорил.
    Все это делалось конечно в свободное от работы время(менеджеры считали это не приносящим профита) — оно ведь мне нужно было-то.
    Т.е. к чему я: заказчику или менеджерам надо предоставлять факты и цифры, глядя на которые они сами попросят вас сделать это все как можно быстрее.
    AN>Запомнился эпизод с выставкой. Решили нверху показать прогу на выставке. Все было протестировано раньше и проблем никаих не было. Но в целях какой то "секретности" пришло указание убрать один параметр из показа очень быстро, так как нужный человек уезжал через час. Ну самое простое, не генерить его. Сделали — нет параметра, побежали относить копию. А во время этого решили просто прогнать базовый функционал. Ну и оказалось выдает полный отстой, так как все забыли, что от этого параметра зависят некоторые базовые подсчеты. А ведь могли и не проверить.

    A_A>>Это как риски покупать или нет новый более мощный компьютер — ты ж его еще не юзал, а только слышал\читал об его возможностях.
    AN>Можно было и подискутировать о правильности данного примера, но ну его.
    Re[6]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Andrii_Avramenko Украина  
    Дата: 21.11.11 20:45
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AN>> Во вторых, в ветке проекта, не только исходники, но и все сопутствующее.


    AVK>Не понял. И при чем тут это сопутствующее?

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

    AN>>В третьих, скорость.


    AVK>Скорость чего?

    Апдейта конечно.
    Или я апдейт сделаю за 10 секунд или буду ждать от трех минут и более — разница очевидна.

    AN>> Если брать с роота обновления, то будет длиться довольно долгое время.


    AVK>Да ну нафик. Долгое время это сколько? 1 минуту? 2?

    Долгое время это 2 минуты в сравнении с 10 секундами.
    И так ежедневно, от пяти раз на день.
    Re[19]: Батники
    От: Andrii_Avramenko Украина  
    Дата: 21.11.11 20:59
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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


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


    Q>Зачем батники, чем MsBuild не устроил?


    Всмысле, запустить msbuild для апдейта NuGet?
    Re[20]: Батники
    От: Qbit86 Кипр
    Дата: 21.11.11 21:01
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

    A_A>Всмысле, запустить msbuild для апдейта NuGet?


    Ну да.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[21]: Батники
    От: Andrii_Avramenko Украина  
    Дата: 21.11.11 21:03
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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


    A_A>>Всмысле, запустить msbuild для апдейта NuGet?


    Q>Ну да.


    так для запуска msbuild не из студии все равно батник нужен
    какой смысл запускать msbuild, который будет запускать NuGet, если мона сразу запустить NuGet?
    Re[22]: Батники
    От: Qbit86 Кипр
    Дата: 21.11.11 21:06
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

    A_A>так для запуска msbuild не из студии все равно батник нужен :)

    A_A>какой смысл запускать msbuild, который будет запускать NuGet, если мона сразу запустить NuGet?

    Чтобы выгрузка пакетов была частью процесса сборки. Т.е. на билд-сервере не нужны никакие ручные запуски каких-то батников. Чистый чекаут репозитория даёт достаточное для сборки окружение.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[23]: Батники
    От: Andrii_Avramenko Украина  
    Дата: 21.11.11 21:11
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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


    A_A>>так для запуска msbuild не из студии все равно батник нужен

    A_A>>какой смысл запускать msbuild, который будет запускать NuGet, если мона сразу запустить NuGet?

    Q>Чтобы выгрузка пакетов была частью процесса сборки. Т.е. на билд-сервере не нужны никакие ручные запуски каких-то батников.

    Именно так и есть.
    Q>Чистый чекаут репозитория даёт достаточное для сборки окружение.
    Только локально, когда делаешь чекаут — NuGet не вызывается, запускаем батник отдельно
    Предполагаю, можно как post-update для svn сделать, но руки еще не дошли
    А вы как это настроили?
    Re[7]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AlexNek  
    Дата: 21.11.11 21:25
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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


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


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


    A_A>>>Мы, собственно, всегда под AnyCPU в Release и собираем — зачем иначе?

    AN>>Попробуйте установить прогу на 64 битную ось.
    A_A>Так сервера на продакшене все 64-битные. Ничего не пересобирается.
    A_A>Оно ж AnyCpu. В чем проблема?
    Может и поэтому, что бильд на 64 или никаких внешних либ не требуется.
    Истоками проблемы специально не интересовался. Но есть два проги, которым пришлось изменить AnyCPU на x86 из за проблем с запуском под 64 битами.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[6]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AlexNek  
    Дата: 21.11.11 21:25
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

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


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

    AN>>Во первых, в репо не один проект.

    AVK>Ну и что? Тебе места на диске жалко?

    Его просто физически не хватит на все.

    AN>> Во вторых, в ветке проекта, не только исходники, но и все сопутствующее.


    AVK>Не понял. И при чем тут это сопутствующее?

    Ну так сделали. Все тесты, документация, бранчи, релизы, сетапы и пр.

    AN>>В третьих, скорость.


    AVK>Скорость чего?

    Скорость обновления.

    AN>> В четвертых, все слепо коммитить запрещено.


    AVK>Ну так и не надо все слепо коммитить.

    Тогда нельзя жать одну конпку один раз.

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


    AVK>И что?

    Коммитится только то что включено в солушин.

    AN>> Если брать с роота обновления, то будет длиться довольно долгое время.


    AVK>Да ну нафик. Долгое время это сколько? 1 минуту? 2?

    Бывает и часы, если все брать с нуля. Вполне может 5-10 минут быть.

    AN>>Но дело ведь не в чтении, но и в записи.


    AVK>И что с ней не так?

    То что нельзя всю солушин коммитить, нужно по частям которые планировалось изменить.
    И про какую-то часть можно забыть.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[13]: NuGet
    От: AlexNek  
    Дата: 21.11.11 21:25
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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


    AN>>Допустим раньше параметр не проверялся на ноль, а теперь сделали. Но вылет все равно проиходит по нулю (Длл-ка не обновилась). Смотрим исходники все нормально, AN>не может там такого быть.

    AN>>Ну а все всегда не перекроешь.
    A_A>Это один из самых неприятных багов.
    A_A>Если версия либы будет соответствовать версии ревизии коммита, то эта проблема уйдет.
    Так поэтому и спрашивал, кто это будет проверять?

    A_A>>>Автоматизация без участия человека не допустит рассогласования исходников с бинарниками.

    AN>>Это будет только в том случае когда прогу также роботы писать будут, а за ними будут другие роботы наблюдать. А так можно почти всегда найти ситуации в которых механизм даст сбой.
    A_A>Давайте расскажу поподробнее за этот механизм.
    A_A>При создании новой версии либы, разработчик делает билд на CI с таргетом "Deploy".
    У нас разработчик не имеет доступа "записи" к CI, все идет чисто на автомате.
    A_A>Если этот проект не поддерживает такой таргет
    A_A>(т.е. не Database project or Web project etc.) тогда мы получим фейл билда и узнаем сразу.
    A_A>Если процесс версионирования NuGet настироен неправильно -> получим фейл билда и узнаем сразу.
    A_A>Итак, билд прошел успешно.
    A_A>Если мы укажем несуществующую версию либы(т.е. кот орой нет физически в фиде NuGet) -> получим фейл апдейта батника NuGet и узнаем чуть по-позже.
    A_A>имхо, вероятность сбоя невелика.
    Не в этой цепочке. Типа как поломали защиту видео ДВД и как крадут секреты/деньги.
    Вот первое, что пришло в голову.
    Исправили два файла, но забыли один закоммитить. Потом вспомнили, закоммитили, после этого кто то взял исходники и начал работать с первым билдом.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[12]: Модули
    От: AlexNek  
    Дата: 21.11.11 21:25
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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


    A_A>>>Делаете пилотные проекты(лучше скопировать текущие самые сложные, с наибольшим количеством зависимостей) — на них играетесь

    AN>>Кто даст время, деньги, ресурсы?
    A_A>Заказчик конечно.
    Во первых, заказчик — это другой отдел. Во вторых, все уже давным давно распланировано и деньги и ресурсы.
    A_A>А вот твоя задача — объяснить ему, что эти затраты для него окупятся Плюс он еще и заработает на этом в ближайшем будущем.
    Вот это совсем туманно. Если бы отличия были настолько существенны все бы использовали одну лучшую систему,а SVN забили бы досками с большой мигалкой — опасно.
    A_A>Насчет ближайшего будущего лучше поделикатней, конечно, без гарантий.
    A_A>>>Потом постепенно переводите текущие на новую систему.
    A_A>>>Риски всегда есть. Чтобы о них узнать заранее нужно проводить ресерч.
    AN>>Прототип можно и за час сделать, а вот уже довести его до ума и подкрутить все мелочи — это уже время.
    A_A>>>А по поводу переходить или нет — выписываешь в список плюсы и минусы существующей системы и новой(насколько возможно собрать информацию)
    A_A>>>и будет ясно.
    AN>>Можно долго и нудно все выписывать и подсчитывать, но вот как быть с неким правилом — "не трогай рабочую систему".
    A_A>Оо, это самое вкусное.
    A_A>На прошлой конторе заказчики были из Израиля — все решения о не то что переводе на что-то более удобное в разработке,
    A_A>а о банальном рефакторинге в легаси-коде(который находится в активной разработке еще), проходили с жуткими боями в виде закидывания аргументами.
    A_A>После замеров времени выполнения трех(самых веселых) методов сервисов бизнес-логики и выкладывания этого всего дела в виде красивых графиков,
    A_A>моя рекомендация по переводу проектов с .NET 2.0 на .NET 4.0 была воспринята без единого спора. (А те проекты были на 2.0 с 2005 года).
    A_A>Разница во времени выполнения была в 7.5 раз
    Ну можно сказать повезло. А если разница была бы в полтора раза?
    И отчего такая разница во времени? Просто у нас также 2.0
    A_A>В старом коде были абсолютно неиспользуемые(т.е. тупо холостые) вызовы методов со стек-трейсом до
    A_A>12 методов, которые даже в базу лезли. Но менеджерам я об этом естесственно не говорил.
    А какие бы были затраты просто оптимизировать существующий код?
    A_A>Все это делалось конечно в свободное от работы время(менеджеры считали это не приносящим профита) — оно ведь мне нужно было-то.
    A_A>Т.е. к чему я: заказчику или менеджерам надо предоставлять факты и цифры, глядя на которые они сами попросят вас сделать это все как можно быстрее.
    Это если есть что измерять.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[24]: Батники
    От: Qbit86 Кипр
    Дата: 21.11.11 21:31
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

    A_A>Только локально, когда делаешь чекаут — NuGet не вызывается, запускаем батник отдельно :crash:

    A_A>Предполагаю, можно как post-update для svn сделать, но руки еще не дошли :crash:
    A_A>А вы как это настроили?

    Каждый проект (который нуждается в NuGet-пакетах) импортирует targets-файл примерно такого вида:
    <?xml version="1.0" encoding="utf-8"?>
    <Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
        <PropertyGroup>
            <NuGetToolsPath>$(Build)</NuGetToolsPath>
            <NuGetExePath>$(NuGetToolsPath)nuget.exe</NuGetExePath>
            <PackagesConfig>$(ProjectDir)packages.config</PackagesConfig>
            <PackagesDir>$(SolutionDir)Packages</PackagesDir>
    
            <!-- Package sources used to restore packages. By default will used the registered sources under %APPDATA%\NuGet\NuGet.Config -->
            <PackageSources>""</PackageSources>
    
            <!-- Enable the restore command to run before builds -->
            <RestorePackages Condition="$(RestorePackages) == ''">true</RestorePackages>
    
            <!-- Commands -->
            <RestoreCommand>"$(NuGetExePath)" install "$(PackagesConfig)" -source $(PackageSources) -o "$(PackagesDir)"</RestoreCommand>
    
            <!-- Make the build depend on restore packages -->
            <BuildDependsOn Condition="$(RestorePackages) == 'true'">
                RestorePackages;
                $(BuildDependsOn);
            </BuildDependsOn>
        </PropertyGroup>
        
        <Target Name="CheckPrerequisites">
            <!-- Raise an error if we're unable to locate nuget.exe  -->
            <Error Condition="!Exists('$(NuGetExePath)')" Text="Unable to locate '$(NuGetExePath)'." />
        </Target>
        
        <Target Name="RestorePackages" DependsOnTargets="CheckPrerequisites">
            <Exec Command="$(RestoreCommand)"
                  LogStandardErrorAsError="true"
                  Condition="Exists('$(PackagesConfig)')" />
        </Target>
    </Project>


    В случае, если нет какого-то пакета из packages.config проекта, он будет скачан командой «nuget.exe install».
    Глаза у меня добрые, но рубашка — смирительная!
    Re[8]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Andrii_Avramenko Украина  
    Дата: 21.11.11 21:33
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

    AN>Истоками проблемы специально не интересовался. Но есть два проги, которым пришлось изменить AnyCPU на x86 из за проблем с запуском под 64 битами.

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

    недавно в наших проектах специально поудалял все конфигунации кроме AnyCPU — чтоб возможности собрать под другую платформу не было
    Re[14]: NuGet
    От: Andrii_Avramenko Украина  
    Дата: 21.11.11 21:35
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

    A_A>>При создании новой версии либы, разработчик делает билд на CI с таргетом "Deploy".

    AN>У нас разработчик не имеет доступа "записи" к CI, все идет чисто на автомате.
    А клиент доступа к CI у вас есть?
    Re[7]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 21.11.11 21:40
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

    AVK>>Не понял. И при чем тут это сопутствующее?

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

    А зачем всякую фигню на сотни мег класть рядом с исходниками?

    AVK>>Да ну нафик. Долгое время это сколько? 1 минуту? 2?

    A_A>Долгое время это 2 минуты в сравнении с 10 секундами.
    A_A>И так ежедневно, от пяти раз на день.

    Да уж, огромная потеря времени.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[7]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 21.11.11 21:40
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

    AVK>>Ну и что? Тебе места на диске жалко?

    AN>Его просто физически не хватит на все.

    То ли у тебя проект несколько сотен гиг, толи работодатель редкий жмот.

    AVK>>Не понял. И при чем тут это сопутствующее?

    AN>Ну так сделали. Все тесты, документация, бранчи, релизы, сетапы и пр.

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

    AVK>>Ну так и не надо все слепо коммитить.

    AN>Тогда нельзя жать одну конпку один раз.

    Почему это? У тебя нет диалога выбора того, что надо коммитить?

    AVK>>И что?

    AN>Коммитится только то что включено в солушин.

    А добавить остальное религия мешает?

    AVK>>Да ну нафик. Долгое время это сколько? 1 минуту? 2?

    AN>Бывает и часы, если все брать с нуля.

    А зачем все брать с нуля? И часы — это, видимо, опять жлобство работодателя.

    AN> Вполне может 5-10 минут быть.


    Ужас то какой.

    AN>>>Но дело ведь не в чтении, но и в записи.

    AVK>>И что с ней не так?
    AN>То что нельзя всю солушин коммитить, нужно по частям которые планировалось изменить.

    Нафига???

    AN>И про какую-то часть можно забыть.


    Ну да, как обычно — создаем себе проблемы, а потом с ними сражаемся.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[13]: Модули
    От: Andrii_Avramenko Украина  
    Дата: 21.11.11 21:59
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

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


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


    A_A>>>>Делаете пилотные проекты(лучше скопировать текущие самые сложные, с наибольшим количеством зависимостей) — на них играетесь

    AN>>>Кто даст время, деньги, ресурсы?
    A_A>>Заказчик конечно.
    AN>Во первых, заказчик — это другой отдел.
    так он всегда и будет "другим отделом". причем попытка на такие разговоры всегда дается только одна — не тщательно подготовился с аргументами
    и ответами на возможные вопросы — второго раза не будет
    AN>Во вторых, все уже давным давно распланировано и деньги и ресурсы.
    Поверь, так будет всегда. Под лежачий камень вода не течет. кстати, сейчас почти оптимальное время — до апреля будет распил бюджета на следующий год

    A_A>>После замеров времени выполнения трех(самых веселых) методов сервисов бизнес-логики и выкладывания этого всего дела в виде красивых графиков,

    A_A>>моя рекомендация по переводу проектов с .NET 2.0 на .NET 4.0 была воспринята без единого спора. (А те проекты были на 2.0 с 2005 года).
    A_A>>Разница во времени выполнения была в 7.5 раз
    AN>Ну можно сказать повезло. А если разница была бы в полтора раза?
    AN>И отчего такая разница во времени? Просто у нас также 2.0
    Разница была конечно, в основном не из-за фреймворка. Там были дикие ненужные ветки выполнения, которые просто не удаляли после изменений.
    В базе были процедуры аля GetCustomerById, вместо этого дергалась GetMemberChildren(CustomerId) — вытягивалась вся простыня кастомеров
    (доходило до 14 тыщ) и в бизнес-логике искался нужный кастомер
    Еще всякие ненужные бешенные циклы по таким коллекциям с тройным уровнем вложенности.
    И все добро всегда выполнялось в одном потоке
    A_A>>В старом коде были абсолютно неиспользуемые(т.е. тупо холостые) вызовы методов со стек-трейсом до
    A_A>>12 методов, которые даже в базу лезли. Но менеджерам я об этом естесственно не говорил.
    AN>А какие бы были затраты просто оптимизировать существующий код?
    так его в итоге и оптимизировали — по модулям, по очереди, начиная с самых важных
    A_A>>Все это делалось конечно в свободное от работы время(менеджеры считали это не приносящим профита) — оно ведь мне нужно было-то.
    A_A>>Т.е. к чему я: заказчику или менеджерам надо предоставлять факты и цифры, глядя на которые они сами попросят вас сделать это все как можно быстрее.
    AN>Это если есть что измерять.
    Так надо найти, даже если и мерять нечего. Когда поставишь цель найти — само найдется.
    Re[25]: Батники
    От: Andrii_Avramenko Украина  
    Дата: 21.11.11 22:04
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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


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

    A_A>>Предполагаю, можно как post-update для svn сделать, но руки еще не дошли
    A_A>>А вы как это настроили?

    Q>Каждый проект (который нуждается в NuGet-пакетах) импортирует targets-файл примерно такого вида:

    [...]
    Q>В случае, если нет какого-то пакета из packages.config проекта, он будет скачан командой «nuget.exe install».
    Так а таргет этот кто дергает при апдейте СКВ?
    Или вы его зашиваете в файлы проектов?
    Re[26]: Батники
    От: Qbit86 Кипр
    Дата: 21.11.11 22:06
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

    A_A>Так а таргет этот кто дергает при апдейте СКВ?

    A_A>Или вы его зашиваете в файлы проектов?

    Нет, не при апдейте — при сборке. Это ж разруливание зависимостей.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[8]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Andrii_Avramenko Украина  
    Дата: 21.11.11 22:12
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

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


    AVK>>>Не понял. И при чем тут это сопутствующее?

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

    AVK>А зачем всякую фигню на сотни мег класть рядом с исходниками?


    Никакой фигни — куча сорцов, причем процентов 70 — легаси кода.
    К примеру в транке две папки двух веток проектов, слабо, но связанных друг с другом. И надо сделать один коммит с изменениями в обоих папках.
    Нажимаешь Check for modifications — и идешь на обед, пока svn все проверит, если чекаутов всякого сопутствующего уже понаделывал.

    AVK>>>Да ну нафик. Долгое время это сколько? 1 минуту? 2?

    A_A>>Долгое время это 2 минуты в сравнении с 10 секундами.
    A_A>>И так ежедневно, от пяти раз на день.

    AVK>Да уж, огромная потеря времени.

    Не скажу, что огромная, но отсутствие оптимизации рабочего процесса присутствует.
    Re[27]: Батники
    От: Andrii_Avramenko Украина  
    Дата: 21.11.11 22:15
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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


    A_A>>Так а таргет этот кто дергает при апдейте СКВ?

    A_A>>Или вы его зашиваете в файлы проектов?

    Q>Нет, не при апдейте — при сборке. Это ж разруливание зависимостей.

    ну да
    как я понял, этот таргет присутствует во всех файлах проектов.
    Зашили его в шаблоны, на которых создаете новые проекты?
    Re[28]: Батники
    От: Qbit86 Кипр
    Дата: 21.11.11 22:18
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

    A_A>как я понял, этот таргет присутствует во всех файлах проектов.

    A_A>Зашили его в шаблоны, на которых создаете новые проекты?

    Да :) Не сам таргет, его импорт:
    <Import Project="$(Build)NuGet.targets" />
    Глаза у меня добрые, но рубашка — смирительная!
    Re[25]: Батники
    От: Andrii_Avramenko Украина  
    Дата: 21.11.11 22:20
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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


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

    A_A>>Предполагаю, можно как post-update для svn сделать, но руки еще не дошли
    A_A>>А вы как это настроили?

    Q>Каждый проект (который нуждается в NuGet-пакетах) импортирует targets-файл примерно такого вида:

    Туплю, тока сейчас эту строчку заметил
    Re[5]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 22.11.11 03:13
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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

    AN>>>Я бы сформулировал следующее. Если проект находится в конечном листе иерарахии проектов, то с целью экономии времени, лучше поключать Длл-ки.
    ГВ>>Да экономия времени-то не ахти какая большая, прямо скажем.
    A_A>Но она есть — и это факт.
    [...]

    Согласен. Я бы всё же посоветовал присмотреться к такому варианту:

    — "Эталонный" солюшен содержит полный комплект ссылок на проекты, но референсы расставлены на бинарные сборки (не на сами проекты);
    — Локальные солюшены каждый может сделать какие угодно, не выкладывая их на SVN: проекты уже готовы к изолированному использованию.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[6]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AlexNek  
    Дата: 22.11.11 10:16
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

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


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

    AN>>>>Я бы сформулировал следующее. Если проект находится в конечном листе иерарахии проектов, то с целью экономии времени, лучше поключать Длл-ки.
    ГВ>>>Да экономия времени-то не ахти какая большая, прямо скажем.
    A_A>>Но она есть — и это факт.
    ГВ>[...]

    ГВ>Согласен. Я бы всё же посоветовал присмотреться к такому варианту:


    ГВ>- "Эталонный" солюшен содержит полный комплект ссылок на проекты,

    Так и есть.
    ГВ>но референсы расставлены на бинарные сборки (не на сами проекты);
    Так референсы то в проектах сидят. Приходится делать копию проекта с другим именем и другим солюшен. Я так "переключаюсь" от бинарников Дев. Экспресса к исходникам.
    Все бы хорошо, но проекты приходится ручками синхронизировать.
    Re[7]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 22.11.11 10:51
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

    ГВ>>но референсы расставлены на бинарные сборки (не на сами проекты);

    AN>Так референсы то в проектах сидят. Приходится делать копию проекта с другим именем и другим солюшен. Я так "переключаюсь" от бинарников Дев. Экспресса к исходникам.

    Зачем? Что-то не совсем тебя понимаю.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[9]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AlexNek  
    Дата: 22.11.11 17:04
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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


    AN>>Истоками проблемы специально не интересовался. Но есть два проги, которым пришлось изменить AnyCPU на x86 из за проблем с запуском под 64 битами.

    A_A>Походу из-за того, что у тех прог были какие-то референсные сборки, собранные под x86.
    A_A>попробуй пересобрать все зависимости под единую платформу.
    Не все можно пересобрать
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[8]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AlexNek  
    Дата: 22.11.11 17:04
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

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


    AVK>>>Ну и что? Тебе места на диске жалко?

    AN>>Его просто физически не хватит на все.

    AVK>То ли у тебя проект несколько сотен гиг, толи работодатель редкий жмот.

    Дело не в проекте, а в проектах. К тому же админ зеркалит все диски с "мастера" как и заказывает "по шаблону" и по умолчанию все получают одинаковый размер. Да и зачем мне локально иметь все версии всех бранчей, всех проектов. Это ведь был вопрос про репозиторий? В одном хранится все, что нужно.

    AVK>>>Не понял. И при чем тут это сопутствующее?

    AN>>Ну так сделали. Все тесты, документация, бранчи, релизы, сетапы и пр.

    AVK>Зачем тесты, документацию класть прям в исходники? И при чем тут бранчи и релизы?

    Они не в исходниках, но в проекте.

    AVK>>>Ну так и не надо все слепо коммитить.

    AN>>Тогда нельзя жать одну конпку один раз.

    AVK>Почему это? У тебя нет диалога выбора того, что надо коммитить?

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

    AVK>>>И что?

    AN>>Коммитится только то что включено в солушин.

    AVK>А добавить остальное религия мешает?

    Пробовали, вначале понраивлось, а потом достало.

    AVK>>>Да ну нафик. Долгое время это сколько? 1 минуту? 2?

    AN>>Бывает и часы, если все брать с нуля.

    AVK>А зачем все брать с нуля? И часы — это, видимо, опять жлобство работодателя.

    А когда уже все перепробовал и не пашет Либо бывает не коммитится, либо не берется.
    Там получается некоторое кол-во гигов.

    AN>> Вполне может 5-10 минут быть.


    AVK>Ужас то какой.

    По таким "мелочам" железячников не беспокоим

    AN>>>>Но дело ведь не в чтении, но и в записи.

    AVK>>>И что с ней не так?
    AN>>То что нельзя всю солушин коммитить, нужно по частям которые планировалось изменить.

    AVK>Нафига???

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

    AN>>И про какую-то часть можно забыть.


    AVK>Ну да, как обычно — создаем себе проблемы, а потом с ними сражаемся.

    А как тогда правильно, без проблем?
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[14]: Модули
    От: AlexNek  
    Дата: 22.11.11 17:04
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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


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


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


    A_A>>>>>Делаете пилотные проекты(лучше скопировать текущие самые сложные, с наибольшим количеством зависимостей) — на них играетесь

    AN>>>>Кто даст время, деньги, ресурсы?
    A_A>>>Заказчик конечно.
    AN>>Во первых, заказчик — это другой отдел.
    A_A>так он всегда и будет "другим отделом". причем попытка на такие разговоры всегда дается только одна — не тщательно подготовился с аргументами
    A_A>и ответами на возможные вопросы — второго раза не будет
    Ну так поэтому и не лезу.
    AN>>Во вторых, все уже давным давно распланировано и деньги и ресурсы.
    A_A>Поверь, так будет всегда. Под лежачий камень вода не течет. кстати, сейчас почти оптимальное время — до апреля будет распил бюджета на следующий год
    Бюджет то не государственный Все проекты, расписаны еще с начала. Да это нужно и должность еще выбить.

    A_A>>>После замеров времени выполнения трех(самых веселых) методов сервисов бизнес-логики и выкладывания этого всего дела в виде красивых графиков,

    A_A>>>моя рекомендация по переводу проектов с .NET 2.0 на .NET 4.0 была воспринята без единого спора. (А те проекты были на 2.0 с 2005 года).
    A_A>>>Разница во времени выполнения была в 7.5 раз
    AN>>Ну можно сказать повезло. А если разница была бы в полтора раза?
    AN>>И отчего такая разница во времени? Просто у нас также 2.0
    A_A>Разница была конечно, в основном не из-за фреймворка.
    По крайней мере, это уже хорошие новости, а то подумал что чего не знаю.
    A_A>Там были дикие ненужные ветки выполнения, которые просто не удаляли после изменений.
    A_A>В базе были процедуры аля GetCustomerById, вместо этого дергалась GetMemberChildren(CustomerId) — вытягивалась вся простыня кастомеров
    A_A>(доходило до 14 тыщ) и в бизнес-логике искался нужный кастомер
    A_A>Еще всякие ненужные бешенные циклы по таким коллекциям с тройным уровнем вложенности.
    A_A>И все добро всегда выполнялось в одном потоке
    A_A>>>В старом коде были абсолютно неиспользуемые(т.е. тупо холостые) вызовы методов со стек-трейсом до
    A_A>>>12 методов, которые даже в базу лезли. Но менеджерам я об этом естесственно не говорил.
    AN>>А какие бы были затраты просто оптимизировать существующий код?
    A_A>так его в итоге и оптимизировали — по модулям, по очереди, начиная с самых важных
    А почему тогда нужно было обязательно 4-ка?
    A_A>>>Все это делалось конечно в свободное от работы время(менеджеры считали это не приносящим профита) — оно ведь мне нужно было-то.
    A_A>>>Т.е. к чему я: заказчику или менеджерам надо предоставлять факты и цифры, глядя на которые они сами попросят вас сделать это все как можно быстрее.
    AN>>Это если есть что измерять.
    A_A>Так надо найти, даже если и мерять нечего. Когда поставишь цель найти — само найдется.
    Пока только нашлось, что прийдется всех пользователей переучивать.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[8]: MSBuild Conditions
    От: AlexNek  
    Дата: 22.11.11 17:04
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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


    AN>>Так референсы то в проектах сидят. Приходится делать копию проекта с другим именем и другим солюшен.


    Q>Вообще-то можно в одном проекте подключить библиотеку и как проект, и как бинарник таким образом, чтобы фактический вариант ссылки легко переключался, скажем, через MSBuild Property, можно даже в локальном приватном user-файле. Что-то вроде:

    Q>
    Q><Reference Condition="'$(MyVariable)' == 'true'">
    Q>  ...
    Q></Reference>
    Q><ProjectReference Condition="'$(MyVariable)' != 'true'">
    Q>  ...
    Q></ProjectReference>
    Q>

    И как это будет выглядеть со стороны студии? (Я имею в виду переключение.) Сейчас просто перегружается солюшин, причем, по имени сразу видно, что активно.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[8]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AlexNek  
    Дата: 22.11.11 17:04
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

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


    ГВ>>>но референсы расставлены на бинарные сборки (не на сами проекты);

    AN>>Так референсы то в проектах сидят. Приходится делать копию проекта с другим именем и другим солюшен. Я так "переключаюсь" от бинарников Дев. Экспресса к исходникам.

    ГВ>Зачем? Что-то не совсем тебя понимаю.

    Зачем переключать или зачем именно так делать?
    Как делать проще/лучше я не знаю. А исходники довольно часто бывают нужны. Но в проекте с исходниками нельзя пользоваться дизайнером.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[9]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 22.11.11 20:53
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

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


    Не знаю зачем. Собственно, в этом и вопрос.

    AVK>>Зачем тесты, документацию класть прям в исходники? И при чем тут бранчи и релизы?

    AN>Они не в исходниках, но в проекте.

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

    AVK>>Почему это? У тебя нет диалога выбора того, что надо коммитить?

    AN>Есть, но кто гарнтирует что чек боксы правильно выберутся?

    Ты гарантируешь, кто ж еще.

    AN> Бывало и не раз что проскакиваешь.


    Что проскакивает?

    AN>Поэтому лучше лишний раз не рисковать.


    Мощный аргумент.
    AVK>>А добавить остальное религия мешает?
    AN>Пробовали, вначале понраивлось, а потом достало.



    AVK>>А зачем все брать с нуля? И часы — это, видимо, опять жлобство работодателя.

    AN>А когда уже все перепробовал и не пашет

    Силен, ничего не скажешь.

    AN>>>То что нельзя всю солушин коммитить, нужно по частям которые планировалось изменить.

    AVK>>Нафига???
    AN>Если случайно получились изменения, которые не требовались.

    Да что ж вы за программисты такие, что у вас изменения получаются случайно?

    AN> Студия, например, любит с проектами играться.


    Да и фик бы с ней, ничего существенного она там не меняет. 2010, кстати, в этом отношении заметно лучше.

    AVK>>Ну да, как обычно — создаем себе проблемы, а потом с ними сражаемся.

    AN>А как тогда правильно, без проблем?

    Я, кажется, уже объяснял.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[6]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Andrii_Avramenko Украина  
    Дата: 22.11.11 21:41
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

    ГВ>Я бы всё же посоветовал присмотреться к такому варианту:


    ГВ>- "Эталонный" солюшен содержит полный комплект ссылок на проекты, но референсы расставлены на бинарные сборки (не на сами проекты);

    ГВ>- Локальные солюшены каждый может сделать какие угодно, не выкладывая их на SVN: проекты уже готовы к изолированному использованию.

    Имхо, геморроя будет еще то количество.
    Если локальные солюшены не чекинить — нафига они вообще нужны тогда?
    Играться с дифом потом еще то удовольствие.
    Re[7]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Andrii_Avramenko Украина  
    Дата: 22.11.11 21:54
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

    ГВ>>- "Эталонный" солюшен содержит полный комплект ссылок на проекты,

    AN>Так и есть.
    ГВ>>но референсы расставлены на бинарные сборки (не на сами проекты);
    AN>Так референсы то в проектах сидят. Приходится делать копию проекта с другим именем и другим солюшен. Я так "переключаюсь" от бинарников Дев. Экспресса к исходникам.
    AN>Все бы хорошо, но проекты приходится ручками синхронизировать.

    Если часто переключаешься, то оптимальнее, наверное, будет сорцы юзать — а танцы с версиями либ будут лишней тратой времени.
    Если либа стабильная(мало багов и изменений) можно либу юзать, а остальные — по сорцам.
    И нафиг не нужно тогда заморачиваться с тем, что в одних проектах либа юзается, а в других исходниках.
    Re[15]: Модули
    От: Andrii_Avramenko Украина  
    Дата: 22.11.11 22:07
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

    AN>А почему тогда нужно было обязательно 4-ка?

    Потому что в WCF 4.0 (на котором и писались проекты) добавили много полезных улучшений и повысили производительность.
    Re[7]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 22.11.11 22:36
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

    ГВ>>Я бы всё же посоветовал присмотреться к такому варианту:

    ГВ>>- "Эталонный" солюшен содержит полный комплект ссылок на проекты, но референсы расставлены на бинарные сборки (не на сами проекты);
    ГВ>>- Локальные солюшены каждый может сделать какие угодно, не выкладывая их на SVN: проекты уже готовы к изолированному использованию.

    A_A>Имхо, геморроя будет еще то количество.

    A_A>Если локальные солюшены не чекинить — нафига они вообще нужны тогда?

    Для работы над отдельными проектами без страха зацепить лишний код.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[9]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 22.11.11 22:53
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

    ГВ>>>>но референсы расставлены на бинарные сборки (не на сами проекты);

    AN>>>Так референсы то в проектах сидят. Приходится делать копию проекта с другим именем и другим солюшен. Я так "переключаюсь" от бинарников Дев. Экспресса к исходникам.
    ГВ>>Зачем? Что-то не совсем тебя понимаю.
    AN>Зачем переключать или зачем именно так делать?
    AN>Как делать проще/лучше я не знаю. А исходники довольно часто бывают нужны. Но в проекте с исходниками нельзя пользоваться дизайнером.

    Ясно. Нет, я немножко про другое говорю.

    Вот смотри, два проекта: App и Lib, которые загружаются в одном солюшене AppLib. При этом App зависит от Lib.

    — В проекте App.csproj проставляем референс на Lib.dll (не путать с референсом на Lib.csproj).
    — В солюшене AppLib проставляем зависимости: App зависит от Lib.

    Тогда, если нам понадобится убрать Lib, чтобы случайно не зацепить его исходники, мы можем просто удалить его из солюшена. Правда, при вставке обратно придётся заново проставить зависимости, поэтому лучше просто сделать новый солюшен — сами .csproj менять при этом не нужно.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[10]: Как лучше подключать подпроекты - DLL или исходники
    От: AlexNek  
    Дата: 23.11.11 19:23
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

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


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


    AVK>Не знаю зачем. Собственно, в этом и вопрос.

    Вопрос не ко мне, а к построителю системы каталогов

    AVK>>>Зачем тесты, документацию класть прям в исходники? И при чем тут бранчи и релизы?

    AN>>Они не в исходниках, но в проекте.

    AVK>Ну так и в чем проблема забирать только исходники тогда?

    В том, что нет такой точки в репо по дереве каталогов из которой можно взять исключительно! только исходники. Хотя можно взять "минимальный набор для компиляции" проекта.

    AVK>>>Почему это? У тебя нет диалога выбора того, что надо коммитить?

    AN>>Есть, но кто гарнтирует что чек боксы правильно выберутся?

    AVK>Ты гарантируешь, кто ж еще.

    В этом то и заключается проблема. И не только для лично меня.

    AN>> Бывало и не раз что проскакиваешь.


    AVK>Что проскакивает?

    Ну не ту строку кликнешь.

    AVK>>>А зачем все брать с нуля? И часы — это, видимо, опять жлобство работодателя.

    AN>>А когда уже все перепробовал и не пашет

    AVK>Силен, ничего не скажешь.

    Уже пару раз бывало, сижу пытаюсь понять/разобраться отчего какая-то операция на SVN не идет. Приходит админ, у него тоже нифига не получается. Ну и зачем еще время тратить, когда можно удалить и скачать по новому.

    AN>>>>То что нельзя всю солушин коммитить, нужно по частям которые планировалось изменить.

    AVK>>>Нафига???
    AN>>Если случайно получились изменения, которые не требовались.

    AVK>Да что ж вы за программисты такие, что у вас изменения получаются случайно?

    Уж не упомню всего что было, но на вскидку рефактор/переименовать.

    AN>> Студия, например, любит с проектами играться.


    AVK>Да и фик бы с ней, ничего существенного она там не меняет. 2010, кстати, в этом отношении заметно лучше.

    А есть уверенность что это сделала именно студия? Нужно смотреть отличия, да и потом под каким тикетом эту фигню коммитить? И потом думать, а отчего это новая версия вдруг появилась.

    AVK>>>Ну да, как обычно — создаем себе проблемы, а потом с ними сражаемся.

    AN>>А как тогда правильно, без проблем?

    AVK>Я, кажется, уже объяснял.

    В этой ветке?
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[8]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AlexNek  
    Дата: 23.11.11 19:23
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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


    ГВ>>>- "Эталонный" солюшен содержит полный комплект ссылок на проекты,

    AN>>Так и есть.
    ГВ>>>но референсы расставлены на бинарные сборки (не на сами проекты);
    AN>>Так референсы то в проектах сидят. Приходится делать копию проекта с другим именем и другим солюшен. Я так "переключаюсь" от бинарников Дев. Экспресса к исходникам.
    AN>>Все бы хорошо, но проекты приходится ручками синхронизировать.

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

    Для "чистой" либы должно быть без разницы, тем более, что исходники "чужие".
    A_A>Если либа стабильная(мало багов и изменений) можно либу юзать, а остальные — по сорцам.
    Проблема использования исходников в данном случае другая. Если что пашет не так, можно или самому рыть или в суппорт писать. И самому рыть удобнее по исходникам в отладчике. Хотя часто получается совместное рытье.
    A_A>И нафиг не нужно тогда заморачиваться с тем, что в одних проектах либа юзается, а в других исходниках.
    Да, для конечных веток пофигу.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[10]: Как лучше подключать подпроекты - DLL или исходники
    От: AlexNek  
    Дата: 23.11.11 19:23
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

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


    ГВ>>>>>но референсы расставлены на бинарные сборки (не на сами проекты);

    AN>>>>Так референсы то в проектах сидят. Приходится делать копию проекта с другим именем и другим солюшен. Я так "переключаюсь" от бинарников Дев. Экспресса к исходникам.
    ГВ>>>Зачем? Что-то не совсем тебя понимаю.
    AN>>Зачем переключать или зачем именно так делать?
    AN>>Как делать проще/лучше я не знаю. А исходники довольно часто бывают нужны. Но в проекте с исходниками нельзя пользоваться дизайнером.

    ГВ>Ясно. Нет, я немножко про другое говорю.


    ГВ>Вот смотри, два проекта: App и Lib, которые загружаются в одном солюшене AppLib. При этом App зависит от Lib.


    ГВ>- В проекте App.csproj проставляем референс на Lib.dll (не путать с референсом на Lib.csproj).

    Зависит компиляция проекта, если интрефейс изменится фиг скомпилируешь.
    ГВ>- В солюшене AppLib проставляем зависимости: App зависит от Lib.
    А на что они еще влияют кроме последовательности сборки/компиляции?

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

    Как то сложно представить удобство переключения солюшен, да и если подключены либы, для чего физически убирать проекты? Да и как в таком случае отлаживать свою либу?
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[11]: Как лучше подключать подпроекты - DLL или исходники
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 23.11.11 19:40
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

    AN>Вопрос не ко мне, а к построителю системы каталогов


    Какой такой системы каталогов?

    AVK>>Ну так и в чем проблема забирать только исходники тогда?

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

    Так я об этом и писал — сам и накосячили, сами потом с граблями и боретесь.

    AN>>>Есть, но кто гарнтирует что чек боксы правильно выберутся?

    AVK>>Ты гарантируешь, кто ж еще.
    AN>В этом то и заключается проблема.

    Не думаю что это проблема.

    AVK>>Что проскакивает?

    AN>Ну не ту строку кликнешь.

    Потрясающе. Честно.

    AVK>>>>А зачем все брать с нуля? И часы — это, видимо, опять жлобство работодателя.

    AN>>>А когда уже все перепробовал и не пашет
    AVK>>Силен, ничего не скажешь.
    AN>Уже пару раз бывало, сижу пытаюсь понять/разобраться отчего какая-то операция на SVN не идет.

    Странно, почему у меня такого не бывает.

    AN> Приходит админ, у него тоже нифига не получается. Ну и зачем еще время тратить, когда можно удалить и скачать по новому.


    Это, значит, админ так у вас рабочие копии сносит?

    AVK>>Да что ж вы за программисты такие, что у вас изменения получаются случайно?

    AN>Уж не упомню всего что было, но на вскидку рефактор/переименовать.

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

    AVK>>Да и фик бы с ней, ничего существенного она там не меняет. 2010, кстати, в этом отношении заметно лучше.

    AN>А есть уверенность что это сделала именно студия? Нужно смотреть отличия

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

    AN>, да и потом под каким тикетом эту фигню коммитить?


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

    AVK>>Я, кажется, уже объяснял.

    AN>В этой ветке?

    В этой.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[11]: Как лучше подключать подпроекты - DLL или исходники
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 23.11.11 19:44
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

    AN>Да и как в таком случае отлаживать свою либу?


    Как обычно. Дебаггеру совершенно пофик на то, на исходник ссылка стоит, или на бинарник в проекте.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[12]: Как лучше подключать подпроекты - DLL или исходники
    От: AlexNek  
    Дата: 23.11.11 23:13
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

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


    AN>>Да и как в таком случае отлаживать свою либу?


    AVK>Как обычно. Дебаггеру совершенно пофик на то, на исходник ссылка стоит, или на бинарник в проекте.

    Если есть PDB Но все равно, помнится, неудобства были. (Хотя бы и по рефакторингу. Тут как раз палка о двух концах.)
    Но речь о том, что исправил я ошибку в исходниках и теперь нужно пересобрать все локально для проверки.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[12]: Как лучше подключать подпроекты - DLL или исходники
    От: AlexNek  
    Дата: 23.11.11 23:13
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

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


    AN>>Вопрос не ко мне, а к построителю системы каталогов


    AVK>Какой такой системы каталогов?

    Человек придумал иерархию каталогов, прежде всего удобную ему. Хотя и довольно логичную.

    AVK>>>Ну так и в чем проблема забирать только исходники тогда?

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

    AVK>Так я об этом и писал — сам и накосячили, сами потом с граблями и боретесь.

    За исключением того что все довольно сильно разнесено во времени

    AN>>>>Есть, но кто гарнтирует что чек боксы правильно выберутся?

    AVK>>>Ты гарантируешь, кто ж еще.
    AN>>В этом то и заключается проблема.

    AVK>Не думаю что это проблема.

    Можно назвать как угодно, но бывает.

    AVK>>>Что проскакивает?

    AN>>Ну не ту строку кликнешь.

    AVK>Потрясающе. Честно.

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

    AVK>>>>>А зачем все брать с нуля? И часы — это, видимо, опять жлобство работодателя.

    AN>>>>А когда уже все перепробовал и не пашет
    AVK>>>Силен, ничего не скажешь.
    AN>>Уже пару раз бывало, сижу пытаюсь понять/разобраться отчего какая-то операция на SVN не идет.

    AVK>Странно, почему у меня такого не бывает.

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

    AN>> Приходит админ, у него тоже нифига не получается. Ну и зачем еще время тратить, когда можно удалить и скачать по новому.


    AVK>Это, значит, админ так у вас рабочие копии сносит?

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

    AVK>>>Да что ж вы за программисты такие, что у вас изменения получаются случайно?

    AN>>Уж не упомню всего что было, но на вскидку рефактор/переименовать.

    AVK>Либо ты переименовал типы, от которых кто то зависит, и тогда надо было коммитить и сторонние проекты, либо ты умудрился переименовать что то, от чего ты сам зависишь, и тогда ты ССЗБ.


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

    Ну а если свое переименовал то это не так страшно.
    AVK>>>Да и фик бы с ней, ничего существенного она там не меняет. 2010, кстати, в этом отношении заметно лучше.
    AN>>А есть уверенность что это сделала именно студия? Нужно смотреть отличия

    AVK>А что, мог ты сам чужие проекты подправить? Я обычно помню, что я в последнем коммите в проектах менял.

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

    AN>>, да и потом под каким тикетом эту фигню коммитить?


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


    Ну так и я о чем, коммитить не нужно, а оно в списке.
    AVK>>>Я, кажется, уже объяснял.
    AN>>В этой ветке?

    AVK>В этой.

    попробую тогда завтра вечерком просмотреть всю ветку. Никогда бы не подумал, что будет столько много сообщений.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[11]: Как лучше подключать подпроекты - DLL или исходники
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 24.11.11 04:58
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

    ГВ>>Ясно. Нет, я немножко про другое говорю.

    ГВ>>Вот смотри, два проекта: App и Lib, которые загружаются в одном солюшене AppLib. При этом App зависит от Lib.
    ГВ>>- В проекте App.csproj проставляем референс на Lib.dll (не путать с референсом на Lib.csproj).
    AN>Зависит компиляция проекта, если интрефейс изменится фиг скомпилируешь.

    Ну да, правильно. Так и должно быть.

    ГВ>>- В солюшене AppLib проставляем зависимости: App зависит от Lib.

    AN>А на что они еще влияют кроме последовательности сборки/компиляции?

    В шарпе — по-моему, больше ни на что. Хорошо здесь то, что зависимости хранятся в .sln, а не в .csproj.

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

    AN>Как то сложно представить удобство переключения солюшен,

    Alt-Tab

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


    "Удалить из солюшена" — это я преувеличил. На деле проще сделать новый .sln.

    Всё это нужно только ради того, чтобы случайно не поменять исходники "чужих" проектов и в то же время иметь возможность собрать из них обновлённые бинарники.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[12]: Как лучше подключать подпроекты - DLL или исходники
    От: AlexNek  
    Дата: 24.11.11 17:30
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

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


    ГВ>>>Ясно. Нет, я немножко про другое говорю.

    ГВ>>>Вот смотри, два проекта: App и Lib, которые загружаются в одном солюшене AppLib. При этом App зависит от Lib.
    ГВ>>>- В проекте App.csproj проставляем референс на Lib.dll (не путать с референсом на Lib.csproj).
    AN>>Зависит компиляция проекта, если интрефейс изменится фиг скомпилируешь.

    ГВ>Ну да, правильно. Так и должно быть.

    А если именно это и нужно?

    ГВ>>>- В солюшене AppLib проставляем зависимости: App зависит от Lib.

    AN>>А на что они еще влияют кроме последовательности сборки/компиляции?

    ГВ>В шарпе — по-моему, больше ни на что. Хорошо здесь то, что зависимости хранятся в .sln, а не в .csproj.

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

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

    AN>>Как то сложно представить удобство переключения солюшен,

    ГВ>Alt-Tab

    Несколько студий одновременно? Стараемся избегать...

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


    ГВ>"Удалить из солюшена" — это я преувеличил. На деле проще сделать новый .sln.


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

    Каким образом соберется бинарник из удаленного из солюшин проекта? Что не доходит.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[13]: Как лучше подключать подпроекты - DLL или исходники
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 25.11.11 09:08
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

    ГВ>>>>Ясно. Нет, я немножко про другое говорю.

    ГВ>>>>Вот смотри, два проекта: App и Lib, которые загружаются в одном солюшене AppLib. При этом App зависит от Lib.
    ГВ>>>>- В проекте App.csproj проставляем референс на Lib.dll (не путать с референсом на Lib.csproj).
    AN>>>Зависит компиляция проекта, если интрефейс изменится фиг скомпилируешь.
    ГВ>>Ну да, правильно. Так и должно быть.
    AN>А если именно это и нужно?

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

    ГВ>>>>- В солюшене AppLib проставляем зависимости: App зависит от Lib.

    AN>>>А на что они еще влияют кроме последовательности сборки/компиляции?
    ГВ>>В шарпе — по-моему, больше ни на что. Хорошо здесь то, что зависимости хранятся в .sln, а не в .csproj.
    AN>Никак не могу понять навар, кроме того, что бильд довольно часто был неправильным, приходилось все полностью перестраивать.

    Ну вам же надо защитить исходники от случайного редактирования?

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

    AN>>>Как то сложно представить удобство переключения солюшен,
    ГВ>>Alt-Tab
    AN>Несколько студий одновременно? Стараемся избегать...

    У-у-у, как всё запущено...

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

    ГВ>>"Удалить из солюшена" — это я преувеличил. На деле проще сделать новый .sln.
    ГВ>>Всё это нужно только ради того, чтобы случайно не поменять исходники "чужих" проектов и в то же время иметь возможность собрать из них обновлённые бинарники.
    AN>Каким образом соберется бинарник из удаленного из солюшин проекта? Что не доходит.

    Он не "соберётся". Его нужно будет собрать, открыв другой солюшен, куда вставлен соответствующий .csproj.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[14]: Как лучше подключать подпроекты - DLL или исходники
    От: AlexNek  
    Дата: 25.11.11 18:11
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

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


    ГВ>>>>>- В солюшене AppLib проставляем зависимости: App зависит от Lib.

    AN>>>>А на что они еще влияют кроме последовательности сборки/компиляции?
    ГВ>>>В шарпе — по-моему, больше ни на что. Хорошо здесь то, что зависимости хранятся в .sln, а не в .csproj.
    AN>>Никак не могу понять навар, кроме того, что бильд довольно часто был неправильным, приходилось все полностью перестраивать.

    ГВ>Ну вам же надо защитить исходники от случайного редактирования?

    А..., если только для этого. А какой критерий переключения между солюшинами?

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

    AN>>>>Как то сложно представить удобство переключения солюшен,
    ГВ>>>Alt-Tab
    AN>>Несколько студий одновременно? Стараемся избегать...

    ГВ>У-у-у, как всё запущено...

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

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

    ГВ>>>"Удалить из солюшена" — это я преувеличил. На деле проще сделать новый .sln.
    ГВ>>>Всё это нужно только ради того, чтобы случайно не поменять исходники "чужих" проектов и в то же время иметь возможность собрать из них обновлённые бинарники.
    AN>>Каким образом соберется бинарник из удаленного из солюшин проекта? Что не доходит.

    ГВ>Он не "соберётся". Его нужно будет собрать, открыв другой солюшен, куда вставлен соответствующий .csproj.

    А как "запретить" пользоваться этим солюшин для обычной работы
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[15]: Как лучше подключать подпроекты - DLL или исходники
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 25.11.11 18:55
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

    ГВ>>Ну вам же надо защитить исходники от случайного редактирования?

    AN>А..., если только для этого. А какой критерий переключения между солюшинами?

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

    AN>>>Несколько студий одновременно? Стараемся избегать...

    ГВ>>У-у-у, как всё запущено...
    AN>Как говорится, были преценденты.

    И в чём же они выражались?

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

    ГВ>>>>"Удалить из солюшена" — это я преувеличил. На деле проще сделать новый .sln.
    ГВ>>>>Всё это нужно только ради того, чтобы случайно не поменять исходники "чужих" проектов и в то же время иметь возможность собрать из них обновлённые бинарники.
    AN>>>Каким образом соберется бинарник из удаленного из солюшин проекта? Что не доходит.
    ГВ>>Он не "соберётся". Его нужно будет собрать, открыв другой солюшен, куда вставлен соответствующий .csproj.
    AN>А как "запретить" пользоваться этим солюшин для обычной работы

    Это ещё зачем? Кто хочет и может следить за руками — пусть работает с большим солюшеном. Ну а не может — да постигнут его... Постоянные шуточки коллег.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[5]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Ziaw Россия  
    Дата: 25.11.11 19:13
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

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


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

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

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

    Thread.Sleep(Randon.Next(3*1000*60*60*24));
    Console.WriteLine("Dude, run msbuild now. Copy output to ....")


    Уверен, что после третьего запуска вы затоскуете и подумаете об оптимизации процесса.
    Re[5]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Ziaw Россия  
    Дата: 25.11.11 19:19
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

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

    AN>Как сделать без локальной версии?
    AN>Загрузился набор Длл-ок теперь требуется делать исправление в одной из них.

    Я русским языком написал как. Надо подключать те dll которые получаются в процессе сборки исходников. Исключение — внешние, по отношению к проекту, библиотеки. Для них лучше использовать NuGet.
    Re[6]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Andrii_Avramenko Украина  
    Дата: 25.11.11 20:25
    Оценка:
    Здравствуйте, Ziaw, Вы писали:

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


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

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

    Z>Проблема в том, что вы предлагаете кроме разработки заниматься не пойми чем. Типа ждать пока коллега даст добро и выкладывать сборки. Попробуйте сами Z>позаниматься подобной работой. Вместо коллеги лучше написать программу.

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

    Z>
    Z>Thread.Sleep(Randon.Next(3*1000*60*60*24));
    Z>Console.WriteLine("Dude, run msbuild now. Copy output to ....")
    Z>

    Может я не понял шутку юмора, но мы msbuild юзаем только для модификаций .msbuild скриптов.
    Ну, и любимый кейс:
    Блин, какого фига на CI тесты падают, а локально работают?

    Z>Уверен, что после третьего запуска вы затоскуете и подумаете об оптимизации процесса.

    А что именно подлежит оптимизации?
    Re[29]: Батники
    От: Andrii_Avramenko Украина  
    Дата: 25.11.11 20:29
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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


    A_A>>как я понял, этот таргет присутствует во всех файлах проектов.

    A_A>>Зашили его в шаблоны, на которых создаете новые проекты?

    Q>Да Не сам таргет, его импорт:

    Q>
    Q><Import Project="$(Build)NuGet.targets" />
    Q>


    Выходит, во время каждого локального билда в студии дергается апдейт NuGet и он проверяет каждый фид?
    Re[7]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Ziaw Россия  
    Дата: 26.11.11 07:53
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

    Z>>Проблема в том, что вы предлагаете кроме разработки заниматься не пойми чем. Типа ждать пока коллега даст добро и выкладывать сборки. Попробуйте сами Z>позаниматься подобной работой. Вместо коллеги лучше написать программу.


    A_A>Честно, не понял выделенного.

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

    Это по вашему сценарию:
    A_A>Нет. Это в корне неправильно. Они что в разных полушариях земли живут без средств коммуникации?
    A_A>Первый кто готов — говорит второму, что закончил и залился.
    A_A>Второй отвественен за релиз новой версии для всех нуждающихся.

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


    Эта фраза говорит о вашей полной некомпетентности в вопросах сборки. Зачем лезть с безапелляционными заявлениями в темы о которых вы практически ничего не знаете?

    A_A>Ну, и любимый кейс:


    A_A>Блин, какого фига на CI тесты падают, а локально работают?


    Видимо очень любимый, раз не желаете с ним расставаться.
    Re[16]: Как лучше подключать подпроекты - DLL или исходники
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 26.11.11 11:36
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

    AN>>>>Несколько студий одновременно? Стараемся избегать...

    ГВ>>>У-у-у, как всё запущено...
    AN>>Как говорится, были преценденты.

    ГВ>И в чём же они выражались?


    Я так чувствую, судя по проблемам с местом на диске для рабочих копий, многочасовым апдейтам, проблемам с запуском студии работают они на каком то фантастически дохлом железе.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[16]: Как лучше подключать подпроекты - DLL или исходники
    От: AlexNek  
    Дата: 26.11.11 13:20
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

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


    ГВ>>>Ну вам же надо защитить исходники от случайного редактирования?

    AN>>А..., если только для этого. А какой критерий переключения между солюшинами?

    ГВ>Ну а какой тут может быть критерий? Когда надо, тогда и переключаешься.

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

    AN>>>>Несколько студий одновременно? Стараемся избегать...

    ГВ>>>У-у-у, как всё запущено...
    AN>>Как говорится, были преценденты.

    ГВ>И в чём же они выражались?

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

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

    ГВ>>>>>"Удалить из солюшена" — это я преувеличил. На деле проще сделать новый .sln.
    ГВ>>>>>Всё это нужно только ради того, чтобы случайно не поменять исходники "чужих" проектов и в то же время иметь возможность собрать из них обновлённые бинарники.
    AN>>>>Каким образом соберется бинарник из удаленного из солюшин проекта? Что не доходит.
    ГВ>>>Он не "соберётся". Его нужно будет собрать, открыв другой солюшен, куда вставлен соответствующий .csproj.
    AN>>А как "запретить" пользоваться этим солюшин для обычной работы

    ГВ>Это ещё зачем? Кто хочет и может следить за руками — пусть работает с большим солюшеном. Ну а не может — да постигнут его... Постоянные шуточки коллег.


    Так дело то не в руках. За всеми вариантами просто можно не уследить.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[6]: Как лучше подключать подпроекты - DLL или исходники ч
    От: AlexNek  
    Дата: 26.11.11 13:20
    Оценка:
    Здравствуйте, Ziaw, Вы писали:

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


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

    AN>>Как сделать без локальной версии?
    AN>>Загрузился набор Длл-ок теперь требуется делать исправление в одной из них.

    Z>Я русским языком написал как. Надо подключать те dll которые получаются в процессе сборки исходников.

    Так это и сеть локальная версия Длл-ки.
    Z>Исключение — внешние, по отношению к проекту, библиотеки. Для них лучше использовать NuGet.
    Внешние, можно сказать не меняются.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[31]: Апдейт
    От: Andrii_Avramenko Украина  
    Дата: 26.11.11 13:29
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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


    A_A>>Выходит, во время каждого локального билда в студии дергается апдейт NuGet и он проверяет каждый фид?


    Q>Апдейт работает инкрементально. Т.е. если пакет нужной версии уже выкачан в папку Packages, то NuGet даже в интернет не лезет.


    Удобно
    Предполагаю, что время дерганья NuGet, пусть даже и вхолостую, весьма ничтожно.
    Надо буит нашим билд инженерам(они за NuGet отвечают) скзать, чтоб также прикрутили.
    Re[8]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Andrii_Avramenko Украина  
    Дата: 26.11.11 13:37
    Оценка:
    Здравствуйте, Ziaw, Вы писали:

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


    Z>>>Проблема в том, что вы предлагаете кроме разработки заниматься не пойми чем. Типа ждать пока коллега даст добро и выкладывать сборки. Попробуйте сами Z>позаниматься подобной работой. Вместо коллеги лучше написать программу.


    A_A>>Честно, не понял выделенного.

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

    Z>Это по вашему сценарию:

    A_A>>Нет. Это в корне неправильно. Они что в разных полушариях земли живут без средств коммуникации?
    A_A>>Первый кто готов — говорит второму, что закончил и залился.
    A_A>>Второй отвественен за релиз новой версии для всех нуждающихся.
    Дык, я и не отрицаю-то
    Кто ждет-то и чего ждет, лучше объясните.

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


    Z>Эта фраза говорит о вашей полной некомпетентности в вопросах сборки. Зачем лезть с безапелляционными заявлениями в темы о которых вы практически ничего не знаете?

    "А судьи кто?" (С)
    А можно по-конкретней?

    A_A>>Ну, и любимый кейс:


    A_A>>Блин, какого фига на CI тесты падают, а локально работают?


    Z>Видимо очень любимый, раз не желаете с ним расставаться.

    А Вы как с ним расстались?
    Re[17]: Как лучше подключать подпроекты - DLL или исходники
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 26.11.11 13:53
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

    ГВ>>>>Ну вам же надо защитить исходники от случайного редактирования?

    AN>>>А..., если только для этого. А какой критерий переключения между солюшинами?
    ГВ>>Ну а какой тут может быть критерий? Когда надо, тогда и переключаешься.
    AN>Ну так всегда и будешь работать с большим.

    С чего бы это?

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

    AN>Для этого есть папочки в солюшине.

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

    AN>>>>>Несколько студий одновременно? Стараемся избегать...

    ГВ>>>>У-у-у, как всё запущено...
    AN>>>Как говорится, были преценденты.
    ГВ>>И в чём же они выражались?
    AN>Точно уже не помню, давно было. Плагины выбрыкивались, нужно помнить в каком порядке их закрывать что бы на следущий день нужный проект открылся.

    Ну... Допустим. Правда, я бы, скорее, плагин снёс в таком случае.

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


    Что осталось? И студия не сказала, что проект обновился?

    AN>Изменения проекта в одном иногда могли приводить к затыку в другой.


    Странно, а что вы за плагины используете?

    ГВ>>>>Он не "соберётся". Его нужно будет собрать, открыв другой солюшен, куда вставлен соответствующий .csproj.

    AN>>>А как "запретить" пользоваться этим солюшин для обычной работы
    ГВ>>Это ещё зачем? Кто хочет и может следить за руками — пусть работает с большим солюшеном. Ну а не может — да постигнут его... Постоянные шуточки коллег.

    AN>Так дело то не в руках. За всеми вариантами просто можно не уследить.


    Не понимаю. Если есть риск случайно поменять и закоммитить исходники из большого солюшена, пользуйся компактным солюшеном с небольшим количеством проектов. Если лениво переключаться — ССЗБ.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[9]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 26.11.11 14:00
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

    AVK>>А зачем всякую фигню на сотни мег класть рядом с исходниками?

    A_A>Никакой фигни — куча сорцов, причем процентов 70 — легаси кода.

    Папки на сотни мегабайт исходников легаси-кода? В воображении сразу рисуется что-то вроде хардкорного C и C++ имени VC6...
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[13]: Как лучше подключать подпроекты - DLL или исходники
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 26.11.11 14:08
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

    AN>>>Уже пару раз бывало, сижу пытаюсь понять/разобраться отчего какая-то операция на SVN не идет.

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

    Удалить-закоммитить-добавить-закоммитить. Проверено, помогает. Будет несколько сложнее восстановить историю изменений, но это, как правило, нужно крайне редко.

    AN>>> Приходит админ, у него тоже нифига не получается. Ну и зачем еще время тратить, когда можно удалить и скачать по новому.

    AVK>>Это, значит, админ так у вас рабочие копии сносит?
    AN>Ну, не так грубо, вначале делается локальная копия. Потом восстанавливается работоспособность, а после исходники.

    И для этого нужен аж целый админ??? Да у вас там синекура — админ папки разработчику чистит.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[18]: Как лучше подключать подпроекты - DLL или исходники
    От: AlexNek  
    Дата: 27.11.11 12:32
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

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


    ГВ>>>>>Ну вам же надо защитить исходники от случайного редактирования?

    AN>>>>А..., если только для этого. А какой критерий переключения между солюшинами?
    ГВ>>>Ну а какой тут может быть критерий? Когда надо, тогда и переключаешься.
    AN>>Ну так всегда и будешь работать с большим.

    ГВ>С чего бы это?

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

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

    AN>>Для этого есть папочки в солюшине.

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

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

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


    ГВ>Что осталось? И студия не сказала, что проект обновился?

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

    AN>>Изменения проекта в одном иногда могли приводить к затыку в другой.


    ГВ>Странно, а что вы за плагины используете?

    Мы вообще больше грешили на студию.

    ГВ>>>>>Он не "соберётся". Его нужно будет собрать, открыв другой солюшен, куда вставлен соответствующий .csproj.

    AN>>>>А как "запретить" пользоваться этим солюшин для обычной работы
    ГВ>>>Это ещё зачем? Кто хочет и может следить за руками — пусть работает с большим солюшеном. Ну а не может — да постигнут его... Постоянные шуточки коллег.

    AN>>Так дело то не в руках. За всеми вариантами просто можно не уследить.


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

    Не сколько лениво, сколько неудобно. Сейчас просто нажимаешь ф5 и ждешь запуска проги. А тут получается нужно бильдить в одном, запускаться в другом, да и еще отключать нугет (которого впрочем пока и нет)
    Да и при бильде все равно получаются "локальные Длл-ки", что вроде неприемлимо.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[14]: Как лучше подключать подпроекты - DLL или исходники
    От: AlexNek  
    Дата: 27.11.11 12:32
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

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


    AN>>>>Уже пару раз бывало, сижу пытаюсь понять/разобраться отчего какая-то операция на SVN не идет.

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

    ГВ>Удалить-закоммитить-добавить-закоммитить. Проверено, помогает. Будет несколько сложнее восстановить историю изменений, но это, как правило, нужно крайне редко.

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

    AN>>>> Приходит админ, у него тоже нифига не получается. Ну и зачем еще время тратить, когда можно удалить и скачать по новому.

    AVK>>>Это, значит, админ так у вас рабочие копии сносит?
    AN>>Ну, не так грубо, вначале делается локальная копия. Потом восстанавливается работоспособность, а после исходники.

    ГВ>И для этого нужен аж целый админ??? Да у вас там синекура — админ папки разработчику чистит.

    Ну он не только для этого, еще кофе принести
    "Поигрался он" пару минут, ничего не получается. Разбираться дольше невыгодно, нужно разработчика "запустить" побыстрее. А удалить и загрузить самое быстрое, если и это ничего не дает тогда можно копать дальше.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[19]: Как лучше подключать подпроекты - DLL или исходники
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 27.11.11 17:19
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

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

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

    Я имел в виду, что эти папочки будут делать в общем, "большом" солюшене со всеми исходниками.

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


    ГВ>>Что осталось? И студия не сказала, что проект обновился?

    AN>Речь о "соурсе контрол" прежде всего. В одном проекте исходники имеют статус "закоммитены", в другом нет.
    AN>>>Изменения проекта в одном иногда могли приводить к затыку в другой.
    ГВ>>Странно, а что вы за плагины используете?
    AN>Мы вообще больше грешили на студию.

    Странно, я такого именно за студией не замечал.

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

    AN>Не сколько лениво, сколько неудобно. Сейчас просто нажимаешь ф5 и ждешь запуска проги. А тут получается нужно бильдить в одном, запускаться в другом, да и еще отключать нугет (которого впрочем пока и нет)

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

    Допустим, у нас есть четыре проекта: LibData, LibLogic, LibCustom, WholeApp. Зависит они друг от друга так:

    — LibData — ни от кого не зависит;
    — LibLogic — зависит от LibData (проставлен референс на LibData.dll);
    — LibCustom — зависит от LibData и LibLogic (проставлен референс на LibData.dll и LibLogic.dll);
    — WholeApp — зависит от LibLogic и LibCustom (проставлен референс на LibLogic.dll и LibCustom.dll).

    Допустим, что нужно работать только с двумя модулями: LibCustom и WholeApp.

    Делаем два солюшена:

    ProjectLargeSolutionMySolution
    LibData*
    LibLogic*
    LibCustom**
    WholeApp**
    Один раз запускаем LargeSolution, чтобы собрать все проекты. Потом открываем MySolution и работаем только в нём. Поскольку ссылки проставлены на бинарные сборки, никаких проблем с отсутствующими проектами нет — нужные бинарники мы собрали на предыдущем шаге. Зато теперь ничего лишнего не мешается. ИМХО, единственный более или менее заметный недостаток — нужно вручную проставить зависимости проектов, чтобы они собирались в правильном порядке. Как раз поэтому я советовал бы сначала сделать один большой солюшен, проставить в нём все зависимости (project dependencies), потом скопировать его под другим именем и выкинуть из него лишние проекты — тогда в солюшене сохранятся правильные зависимости для оставшихся.

    AN>Да и при бильде все равно получаются "локальные Длл-ки", что вроде неприемлимо.


    Что значит "локальные длл-ки" и почему они не приемлемы? Как я понимаю, в любом случае всё прогоняется через билд-сервер.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[7]: Как лучше подключать подпроекты - DLL или исходники ч
    От: Ziaw Россия  
    Дата: 28.11.11 03:27
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

    Z>>Я русским языком написал как. Надо подключать те dll которые получаются в процессе сборки исходников.

    AN>Так это и сеть локальная версия Длл-ки.

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

    Z>>Исключение — внешние, по отношению к проекту, библиотеки. Для них лучше использовать NuGet.

    AN>Внешние, можно сказать не меняются.

    Это как раз полезно.
    Re[10]: Как лучше подключать подпроекты - DLL или исходники
    От: Andrii_Avramenko Украина  
    Дата: 28.11.11 18:45
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

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


    AVK>>>А зачем всякую фигню на сотни мег класть рядом с исходниками?

    A_A>>Никакой фигни — куча сорцов, причем процентов 70 — легаси кода.

    ГВ>Папки на сотни мегабайт исходников легаси-кода?

    Это транк одного из репозиториев.
    TempTrunk.jpg
    Более гектара исходников с бинарными зависимостями без документации, файлов с данными, ресурсов.
    ГВ>В воображении сразу рисуется что-то вроде хардкорного C и C++ имени VC6...
    Хорошее такое, воображение
    Re[11]: Как лучше подключать подпроекты - DLL или исходники
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 28.11.11 20:50
    Оценка:
    Здравствуйте, Andrii_Avramenko, Вы писали:

    ГВ>>Папки на сотни мегабайт исходников легаси-кода?

    A_A>Это транк одного из репозиториев.
    A_A>TempTrunk.jpg
    A_A>Более гектара исходников с бинарными зависимостями без документации, файлов с данными, ресурсов.

    Так исходников там сколько от этого объёма?

    ГВ>>В воображении сразу рисуется что-то вроде хардкорного C и C++ имени VC6...

    A_A>Хорошее такое, воображение

    Это из осознанного, дальше вообще химеры из подсознания, от них — полный улёт.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[16]: Как лучше подключать подпроекты - DLL или исходники
    От: AlexNek  
    Дата: 29.11.11 18:04
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

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


    AN>>"Поигрался он" пару минут, ничего не получается.


    AVK>Значит такая у него компетенция.

    А какие будут лучшие предложения? Изучить код SVN/Черепахи и найти источник проблем?
    Помнишь байку про специалиста? Оригинальный тект забылся, но где то так: Поломалась сложная машина на заводе, весь завод стоит, все на ушах, не могут найти в чем причина. Чертежи разложили, прошлись по каждой детальке, ничего не помогает. Через день решили позвать Специалиста, он пришел, пощупал, понюхал, послушал, попросил кувалду и вдарил по одному месту — все заработало. Когда он озвучил сумму гонорара, директор офигел и спросил, отчего такая сумма за 10 минут работы? — "Оттого, что я знаю где и как нужно ударить".

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


    AVK>И все конфиги, батники, логи и что там еще разработчик нешарабельного наплодил — все коту под хвост Похоже, на админе твой работодатель тоже съэкономил.

    Я же вроде уже писал, что вначале все копируется, затем восстанавливается работоспобность, а затем восстанавливается первоначальное состояние рабочего каталога. Тем более, это только с некоторыми каталогами бывает. Да и то сами теперь делаем.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[17]: Как лучше подключать подпроекты - DLL или исходники
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 29.11.11 18:07
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

    AN>А какие будут лучшие предложения? Изучить код SVN/Черепахи и найти источник проблем?


    В 99% случаев помогает просто апдейт. В остальных достаточно найти проблемный каталог и удалить только его.

    AVK>>И все конфиги, батники, логи и что там еще разработчик нешарабельного наплодил — все коту под хвост Похоже, на админе твой работодатель тоже съэкономил.

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

    Ты ж только что рассказывал про много много гигабайтов рабочей копии. Это развлечение с копированием сколько длится?
    ... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[18]: Как лучше подключать подпроекты - DLL или исходники
    От: AlexNek  
    Дата: 29.11.11 19:19
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

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


    AN>>А какие будут лучшие предложения? Изучить код SVN/Черепахи и найти источник проблем?


    AVK>В 99% случаев помогает просто апдейт.

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

    AVK>>>И все конфиги, батники, логи и что там еще разработчик нешарабельного наплодил — все коту под хвост Похоже, на админе твой работодатель тоже съэкономил.

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

    AVK>Ты ж только что рассказывал про много много гигабайтов рабочей копии. Это развлечение с копированием сколько длится?

    А где я говорил, что вся копия сносится?
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
    Re[19]: Как лучше подключать подпроекты - DLL или исходники
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 29.11.11 19:25
    Оценка:
    Здравствуйте, AlexNek, Вы писали:

    AVK>>В 99% случаев помогает просто апдейт.

    AN>-Вчера один решил сделать апдейт черепахи

    Апдейт рабочей копии.

    AVK>>В остальных достаточно найти проблемный каталог и удалить только его.

    AN>ну именно так и поступали, может я непонятно описАл.

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

    AVK>>Ты ж только что рассказывал про много много гигабайтов рабочей копии. Это развлечение с копированием сколько длится?

    AN>А где я говорил, что вся копия сносится?

    Т.е. ты сам уже не помнишь? Силен.

    AVK>>>>Да ну нафик. Долгое время это сколько? 1 минуту? 2?
    AN>>>Бывает и часы, если все брать с нуля.
    AVK>>А зачем все брать с нуля? И часы — это, видимо, опять жлобство работодателя.
    AN>А когда уже все перепробовал и не пашет Либо бывает не коммитится, либо не берется.
    AN>Там получается некоторое кол-во гигов.

    ... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[20]: Как лучше подключать подпроекты - DLL или исходники
    От: AlexNek  
    Дата: 30.11.11 17:43
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

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


    AVK>>>Ты ж только что рассказывал про много много гигабайтов рабочей копии. Это развлечение с копированием сколько длится?

    AN>>А где я говорил, что вся копия сносится?

    AVK>Т.е. ты сам уже не помнишь? Силен.

    AVK>

    AVK>>>>>Да ну нафик. Долгое время это сколько? 1 минуту? 2?
    AN>>>>Бывает и часы, если все брать с нуля.
    AVK>>>А зачем все брать с нуля? И часы — это, видимо, опять жлобство работодателя.
    AN>>А когда уже все перепробовал и не пашет Либо бывает не коммитится, либо не берется.
    AN>>Там получается некоторое кол-во гигов.

    ааа... так это совершенно разные контексты были. В этом я просто попробовал вспомнить хоть какой то пример.
    И как раз просто по обезьянни сделали, как было с каталогами. Может еще были какие то варианты, но не закрепились.То бишь с админом это у меня ну никак не ассоциировалось.
    Cообщение написано в &lt;&lt; RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461&gt;&gt;
     
    Подождите ...
    Wait...
    Пока на собственное сообщение не было ответов, его можно удалить.