Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, Andrii_Avramenko, Вы писали:
A_A>>А кстати, если у SVN репзитория менять svn:externals, то хранится ли в истории эта информация?
H>Естественно.
Так тогда чем распределенные СКВ в данном случае лучше серверных?
Re[6]: Как лучше подключать подпроекты - DLL или исходники ч
Здравствуйте, Andrii_Avramenko, Вы писали:
WH>>Ибо когда правишь код во внешнем модуле, сразу же должен создаваться новый бранч для этого кода. A_A>А какая СКВ позволяет делать это автоматически?
ClearCase хорошо с бранчами умеет работать. Например, позволяет собрать бранч из отдельных файлов любых веток и версий. Она вообще много чего позволяет. Но денег стоит ($4600/user).
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[2]: Как лучше подключать подпроекты - DLL или исходники ч
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>А всякие параноидальные "защиты" — это всё детсад, напакостить при желании можно где угодно. Скажем, кто-то даст кому-то по дружбе доступ к репозиторию... ГВ>Короче, всё это разговоры в пользу бедных — организационные задачи техничесиким средствами не решаются.
Кстати вот на перекрестках есть светофоры — они предназначены разруливать организационную задачу — ПДД
Что происходит если эта организационная задача(в нашем случае возможность изменения чужого кода) будет нарушена:
1) Возможны жертвы участников(в нашем случае девелоперы)
2) Вызывается гаишник в качестве судьи (в нашем случае проджект менеджер)
3) Выносится наказание(в итоге у кого-то будут неприятности)
В итоге в развитых странах начали переходить на путепроводы везде где возможно.
И теперь наша организационная задача не может быть нарушена в принципе.(И никто в компании не имеет проблем в принципе).
Является ли эта защита параноидальной?
Re[9]: Как лучше подключать подпроекты - DLL или исходники ч
Здравствуйте, 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 или исходники ч
Здравствуйте, Andrii_Avramenko, Вы писали:
ГВ>>А всякие параноидальные "защиты" — это всё детсад, напакостить при желании можно где угодно. Скажем, кто-то даст кому-то по дружбе доступ к репозиторию...
A_A>кстати в логах то будет аккаунт именно того кто даст доступ по дружбе, A_A>так что тут уж дружба-дружбой а аккаунты врознь
Ага-ага.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[16]: Как лучше подключать подпроекты - DLL или исходники
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, Andrii_Avramenko, Вы писали:
A_A>>Пример: A_A>>Пришел новый человек в комманду, предпочитающий разбираться во всем самостоятельно и лишний раз никого "глупыми" вопросами не отвлекать.
ГВ>Ну и что? Почти все такие.
A_A>>Ему повесили таску пофиксить багу в функионале, который юзает чужой код. A_A>>И тим-лид забыл ему сказать, что тот код трогать низзя.
ГВ>По ушам тимлиду. Сходу и без разговоров. Что значит, "забыл сказать"? А для пописать он в уборную не забыл сходить?
A_A>>Он разбираясь в баге узнал, что виноват чужой код, пофиксал его(на скорую руку) и закоммитил. A_A>>ну, результаты уже мы знаем
ГВ>Если тимлид такой дурак, что "забывает" сказать про важнейший момент — нах такого тимлида. Это какая-то шиза, право слово.
A_A>>В итоге по шапке получит тим-лид за то что забыл сказать, а неприятности будут у всех. A_A>>Вероятность то есть.
ГВ>Зато в следующий раз таких неприятностей не будет. А мелкие технические недоразумения — чепуха.
По ушам то надавать дело всегда нехитрое.
А в случае с бинарями новичок придет к лиду, что бага в такой-то библиотеке и чего дальше делать-то мол.
И вопрос будет решаться теми, кто несет ответственность за эти модули со 100-процентной вероятностью.
Re[3]: Как лучше подключать подпроекты - DLL или исходники ч
Здравствуйте, Andrii_Avramenko, Вы писали:
ГВ>>А всякие параноидальные "защиты" — это всё детсад, напакостить при желании можно где угодно. Скажем, кто-то даст кому-то по дружбе доступ к репозиторию... ГВ>Короче, всё это разговоры в пользу бедных — организационные задачи техничесиким средствами не решаются. A_A>Кстати вот на перекрестках есть светофоры — они предназначены разруливать организационную задачу — ПДД
Ну началось... Светофоры решают задачу "подать сигнал водителям", чем способствуют решению задачи управления трафиком. А ПДД регламентируют поведение водителей при получении того или иного сигнала (ГИБДД контролирует). Сам по себе светофор без ПДД и ГИБДД — никому не нужная мигалка.
A_A>Что происходит если эта организационная задача(в нашем случае возможность изменения чужого кода) будет нарушена:
Будут нарушены ПДД, а не организационная задача.
A_A>[...] A_A>Является ли эта защита параноидальной?
Плохая аналогия.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[11]: Как лучше подключать подпроекты - DLL или исходники
Здравствуйте, Andrii_Avramenko, Вы писали:
A_A>А в случае с бинарями новичок придет к лиду, что бага в такой-то библиотеке и чего дальше делать-то мол.
А как он узнает, что бага в такой-то библиотеке а не в его коде?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[17]: Как лучше подключать подпроекты - DLL или исходники
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, Andrii_Avramenko, Вы писали:
H>>>Естественно.
A_A>>Так тогда чем распределенные СКВ в данном случае лучше серверных?
H>Тем что они распределенные. В git-е кроме submodule (аналог svn:externals) есть subtree.
не понимаю профита.
Пример из SVN:
1)Есть общий функционал в транке
2)Клиенты юзают различные номера ревизий этого функционала
со все этим SVN справляется, в чем геморрой-то будет?
Re[4]: Как лучше подключать подпроекты - DLL или исходники ч
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, Andrii_Avramenko, Вы писали:
ГВ>>>А всякие параноидальные "защиты" — это всё детсад, напакостить при желании можно где угодно. Скажем, кто-то даст кому-то по дружбе доступ к репозиторию... ГВ>Короче, всё это разговоры в пользу бедных — организационные задачи техничесиким средствами не решаются. A_A>>Кстати вот на перекрестках есть светофоры — они предназначены разруливать организационную задачу — ПДД
ГВ>Ну началось... Светофоры решают задачу "подать сигнал водителям", чем способствуют решению задачи управления трафиком. А ПДД регламентируют поведение водителей при получении того или иного сигнала (ГИБДД контролирует). Сам по себе светофор без ПДД и ГИБДД — никому не нужная мигалка.
Организационная задача — сделать дорожное движение безопасным.
Организационный инструмент решения этой задачи — Правила дорожного движения.
Технический инструмент решения этой задачи — путепровод.
A_A>>Что происходит если эта организационная задача(в нашем случае возможность изменения чужого кода) будет нарушена:
ГВ>Будут нарушены ПДД, а не организационная задача.
A_A>>[...] A_A>>Является ли эта защита параноидальной?
ГВ>Плохая аналогия.
имхо, аналогия очевидна — избавляемся от рисков получения потенциальных проблем в редких случаях
Re[12]: Как лучше подключать подпроекты - DLL или исходники
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, Andrii_Avramenko, Вы писали:
A_A>>А в случае с бинарями новичок придет к лиду, что бага в такой-то библиотеке и чего дальше делать-то мол.
ГВ>А как он узнает, что бага в такой-то библиотеке а не в его коде?
К примеру при вызове метода поймает NotImplementedException
Re[3]: Как лучше подключать подпроекты - DLL или исходники ч
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Andrii_Avramenko, Вы писали:
A_A>>ИМХО, однозначно только использовать подключение библиотек. WH>хъ WH>Это все прекрасно делается с нормальными системами контроля версий
Здравствуйте, Andrii_Avramenko, Вы писали:
ГВ>>Ну началось... Светофоры решают задачу "подать сигнал водителям", чем способствуют решению задачи управления трафиком. А ПДД регламентируют поведение водителей при получении того или иного сигнала (ГИБДД контролирует). Сам по себе светофор без ПДД и ГИБДД — никому не нужная мигалка.
A_A>Организационная задача — сделать дорожное движение безопасным.
Нет, это общая задача, даже скорее требование — снизить аварийность на определённых участках. Для её решения применяются организационные и технические средства. Каждое из них решает свои задачи. Организационные — начальники-подчинённые, кто за что отвечает и т.п. Они вырабатывают правила, фиксируют их на бумаге, придумывают порядок обучения водителей правилам. Дальше задействуются технические средства — светофоры, путепроводы, книгоиздание.
A_A>Организационный инструмент решения этой задачи — Правила дорожного движения.
В некотором роде — да, только эти правила кто-то должен напечатать, кто-то должен прочитать, а кто-то — проследить, что их прочли и правильно поняли. Вот, собственно, это как раз набор организационных задач: кто и как будет собирать людей, кто и как будет их обучать, кто и как будет принимать экзамены и кто и как будет контролировать выполнение правил. Когда эти задачи решены, вся система будет работать.
При необходимости, скажем, светофор может быть заменён регулировщиком, потому что на нём лежит очень простая задача: выдавать некоторые строго определённые сигналы с некоторой периодичностью (или по ситуации, если регулировщик).
A_A>Технический инструмент решения этой задачи — путепровод.
Ну тоже, в общем, верно, но это инструмент решения очень узкой и частной задачи — развязать трафик в определённом узле, а всех остальных задач он не снимает. По-прежнему кто-то должен рассказать о том, как надо понимать разметку, что означают дорожные знаки, как нумеруются полосы, как правильно перестраиваться и т.п. То есть весь цикл обучения ПДД от этого никуда не девается. А решение строить путепровод принимается после обсчётов экономической пользы от такой стройки: каждый перекрёсток развязкой не заменишь.
Тут уместна аналогия с разработкой софта — всё равно тимлиды или ПМы должны объяснять новичкам правила работы в организации, вне зависимости от того, какие технические инструменты там используются. То есть "забыл рассказать", это, считай, выпустил необученного водителя на дорогу. Такое встречается, увы, но зачем уподобляться?
ГВ>>Плохая аналогия. A_A>имхо, аналогия очевидна — избавляемся от рисков получения потенциальных проблем в редких случаях
Разве что очень поверхностная. На самом деле тут вопрос в цене. ИМХО, всяко проще объяснить людям, что не надо лазить в чужой код (читай, рассказать о правилах перестроения), чем выдумывать сложные инструментальные подходы (читай, строить отдельный путепровод для каждого маршрута из всех точек А во все точки Б).
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[13]: Как лучше подключать подпроекты - DLL или исходники
Здравствуйте, Andrii_Avramenko, Вы писали:
ГВ>>А как он узнает, что бага в такой-то библиотеке а не в его коде? A_A>К примеру при вызове метода поймает NotImplementedException
А как он будет такую проблему решать? Неужели кинется дописывать код?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re: Как лучше подключать подпроекты - DLL или исходники чере
ч AN>Для MSVC, под виндами, С#, winforms, если что. AN>Временами на работе возникают дискуссии, что подключать лучше в солюшин как внешние ссылки при наличии исходников — DLL-ки или проекты. AN>Понятно что абсолютно однозначного ответа нет, зависит от конкретной ситуации. Допустим, когда исходники стабильные и практически не меняются, либо от кого-то другого, то видимо DLL-ки с PDB (и отдельными исходниками для отладки) лучше. По крайней мере, нет никакой возможности изменить непреднамеренно код.
AN>Речь же идет исключительно об исходниках текущего проекта, собираемого из многих подпроектов. Просто часто сталкивался, когда исходники чуть чуть отличаются от ДЛЛ-ки и фиг поймешь отчего вдруг не работает/вылетает. Хотя некоторые имеют мнение, что при наличии решарпера и многих разработчиков лучше пользовать исключительно ДЛЛ-ки, несмотря на наличие в солюшин всех требуемы подпроектов с исходниками. А то что кто то забудет актуальную версию загрузить, нужно регулировать постановлениями партии и правительства AN>Хотелось бы услышать различные мнения за и против каждого из подходов, чтобы не ругатся до состояния "пены у рта".
Здравствуйте, Andrii_Avramenko, Вы писали:
A_A>Здравствуйте, AlexNek, Вы писали:
A_A>>>1) Если нет человека с такой должностью — нужно завести должность и взять человека AN>>А зачем, когда можно вполен обойтись без него просто использую другой подход. A_A>Так в чем проблема? Используйте тот подход, который для Вас более выгоден.
Хотелось бв иметь какие то критерии для выборато гото или иного подхода.
Получается тогда для подхода с Длл-ками желателен отдельный человек.
A_A>>>Извини, но с таким подходом к разработке надо улучшать процессы разработки. A_A>>>Создается новая версия библиотеки -> она выкладывается куда-то в шару -> делается описание внесенных изменений -> идут уведомления клиентам о новой версии. AN>>Дело не идет о библиотеке и внешних клиентах, там все по другому. Разговор о команде разрабатывающей достаточно большой проект, скажем с полтинником подпроектов. И все проиходит именно на этапе разработки.
A_A>Вот именно в этом случае пригодится юзание библиотек. A_A>Если был бы простенький проект на 2-3 человека с 10-15 проектами — тогда бы овчинка выделки не стоила и юзание сорцов по ссылке было удобнее.
Честно говоря, не вижу зависимости удобства от количества, если не учитывать какие то определенные параметры, например время компиляции (в данном случаем им можно пренебречь). То бишь нужно определится с критериями.
Здравствуйте, Andrii_Avramenko, Вы писали:
A_A>Здравствуйте, AlexNek, Вы писали:
AN>>Значит голос за Длл-ки? A_A>А как быть тогда с совмещением ссылок на Длл-ки и проекты? A_A>Можно по-детальней?
Допустим есть решение использовать подключение через Длл-ки, тогда абсолютно все проекты обязаны подключаться как Длл-ки, а Длл-ки браться из одного места. Что тогда делать разработчику Длл-ки?
Ведь ему вначале нужно иметь локальную копии для проверки/тестирования, а наличие копии входит в противоречие с требованием "одного источника". Точнее, это требование является необходимым для "внутренностей" ветки иерархии проектов/Длл-ок. Окончания веток- листики этому требования не подчиняются. Их можно включать как нужно в данной ситуациии. A_A>Что делать разработчику именно этой Длл-ки в проекте? A_A>тут есть два варианта: A_A>1)Длл-ка принадлежит другой команде — вносится тикет на создание в ней фичи и ждем, когда эта команда нам выдаст новую длл-ку.
Тут видимо подразумевается, что проект принадлежит конечному листу иерархии проектов. A_A>2)длл-ка наша — мы сами с ней делаем что хотим и не ждем никогда
Вот именно ждать и нужно. "Владелец" Длл-ки нужен вначале найти и исправить проблему, а остальные ждут пока будет готова очереная порция Длл-ок. Хотя можно сказать, берите файл х проекта У. К тому-же разработчик при создании локальной Длл-ки, должне пользоваться "другим источником" — исходниками. А при использовании второго источника должна быть гарантия, что эти два истоника синхронизированы. К тому нужно иметь и локалный механизм "подмены" Длл-ок. A_A>И что делать остальным когда исходники уже в репозитории, но бильд длл-ок еще не готов. Ждать пока не будет все готово и после все брать? A_A>Тут надо это дело автоматизировать, конечно. A_A>Унас так: A_A>1)коммитим исходники A_A>2)берем номер нового билда A_A>3)меняем на клиенте версию на новую A_A>4)запускаем батник A_A>И все. A_A>А если в это же время закоммитились другие изменения, которые нужно пока избежать? (Допустим они исправили генерацию данных, и неправильные данные для теста уже получить просто невозможно) A_A>Это сложный вопрос. Опять же: A_A>1) Если длл-ка ваша — то вы всегда в курсе всех изменений
Даже если и в курсе, нужно отслеживать и исходники и бинарники (в случае подключения Длл-ок), да и еще желательно знать зависимости бинарников. A_A>2) Тут надо отслеживать все изменения с текущей версии по ту, которую хотите заюзать. A_A>То есть нужно отслеживать два источника: исходники и бинарники, и к тому же учитывать иерархию бинарников. A_A>1) Если длл-ка ваша — вы следитие только за сорцами — на версии вам пофиг
Пофиг не могут быть, ведь подключаются только Длл-ки. (Не говорим о "конечных листиках") A_A>2) Следите только за изменениями в функционале и версиями — на сорцы вам пофиг
на сорцвы не пофиг, откуда бильдить локальные версии на время правки?
Здравствуйте, Andrii_Avramenko, Вы писали:
A_A>Здравствуйте, AlexNek, Вы писали:
AN>>Здравствуйте, Andrii_Avramenko, Вы писали:
A_A>>>Здравствуйте, AlexNek, Вы писали:
A_A>>>>>ИМХО, однозначно только использовать подключение библиотек. A_A>>>>>Назовем ради примера: A_A>>>>>общая часть — сервер, A_A>>>>>пользователи общей части — клиенты. AN>>>>То есть пример практически не связанного кода. Максимум — протоколы обмена, видимо. A_A>>>Отнюдь не только. Библиотеки .NET Framework — это связанный код с твоими проектами или нет? AN>>А у меня есть исходники .NET Framework в проекте? A_A>Догадываюсь, что нету. A_A>Так значит юзание библиотек является достаточным.
Это для случая когда библиотека является окончанием иерархии, а чужая библиотека обычно этому требования подчиняется. Иначе говоря, у нас нет исходников базовых классов библиотеки или каких либо ее частей, которые нам нужно изменять. Абсолютно любая часть библиотеки будет всего конечным листом для нашего проекта.
Именно только этом случае это будет достаточным.
А для пописать он в уборную не забыл сходить?
