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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот именно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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