а как вообще народ поступает когда у нас есть например
10 продуктов, которые например используют одну общую библиотеку.
Для этой либы создается одна папка как для продукта или же у каждого продукта есть своя папка с шаред либами
я всегда использовал вариант 1, но всегда были проблемы с тем что сложно было закомитить один проект не трогая другие, потому что его зависимости находятся на уровне с ним всеми остальными, т.е. мне нужно было выбрать некоторые папки игнорируя остальные, причем помнить какие из них нужны для коммита данного продукта.
еще есть проблема с тем, что проапдейтив либу ради одного продукта придется потом проапдейтить и все прочие продукта ее юзающие, а это не всегда нужно, многие продукта могут использовать старую версию.
в общем в итоге я начал сейчас склоняться к идее хранить все, что касается одного продукта в одной папке с ним.
а у суровых мужиков как?
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Re: Организация репозитария для shared компонентов
Здравствуйте, Kingofastellarwar, Вы писали:
K>а как вообще народ поступает когда у нас есть например K>10 продуктов, которые например используют одну общую библиотеку. K>Для этой либы создается одна папка как для продукта или же у каждого продукта есть своя папка с шаред либами
...
K>в общем в итоге я начал сейчас склоняться к идее хранить все, что касается одного продукта в одной папке с ним.
K>а у суровых мужиков как?
Слишком размытое описание. Очень многое зависит от порядка построения процесса релиза, от системы контроля версий, вообще от построенного процесса разработки.
Но в целом, "общая библиотека" — она и должна быть общей, не привязанной к проектам и, соответственно, не лежащей вместе с остальным кодом проекта.
Если эту стороннюю библиотеку приходится часто допиливать под проект — тогда уже или перевходить к варианту 2, или придумывать схему между вариантами 1 и 2. В общем, конкретики мало.
Телепаты в отпуске, телепалка у них.
Во-первых, этот вопрос у управлению проектами имеет отдаленное отношение.
Во-вторых, вы бы хоть указали, что за технологии используются. А то, может, вы на Java пишете, и там уже все многократно украдено с помощью Maven.
В-третьих, какие папки? О чем речь, о проекте в дереве source control software? Или о рабочей директории разработчика?
Иными словами, — подробности — в студию. Что делаете, зачем, на каких технологиях, что используете.
Re[2]: Организация репозитария для shared компонентов
Здравствуйте, Aquary, Вы писали:
A>Слишком размытое описание. Очень многое зависит от порядка построения процесса релиза, от системы контроля версий, вообще от построенного процесса разработки. A>Но в целом, "общая библиотека" — она и должна быть общей, не привязанной к проектам и, соответственно, не лежащей вместе с остальным кодом проекта. A>Если эту стороннюю библиотеку приходится часто допиливать под проект — тогда уже или перевходить к варианту 2, или придумывать схему между вариантами 1 и 2. В общем, конкретики мало.
ну я не знаю какая тут конкретика нужна
ну пусть есть 10 продуктов на с++
в кадром продукте пусть будет где-то по 5 проектов
и есть 10 общих библиотек. тут уточним, что некоторых из этих либ — базовые для всех проектов, а некоторые используются только по необходимости
как хранить это на диске?
и как организовать это всё в сурсконтроле?
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Re[3]: Организация репозитария для shared компонентов
Здравствуйте, Aquary, Вы писали:
A>В правильно поставленном вопросе — половина ответа. "сурсконтрол" — это самая конкретная конкретика в данном случае.
ну ладно конкретный пример для vc++:
имеем на диске такие папки:
// внешние либы от сторонник разработчиков. используются везде. обновляются очень редко
externals/lib-0
externals/lib-1
externals/lib-2
// модули — проекты общие для всех продуктов, но в тоже время часто редактируются в процессе девелопмента продуктов
module-0
module-1
module-2
//продукт А состоит из двух проектов(эти проекты используются только этим продуктом и никаких не реюзятся), эти проекты референсятся/используют/линкуют часть modules и часть external lib
product-A/project-A-0
product-A/project-A-1
//продукт В состоит из трёх проектов и как и А использует modul`и и external lib`ы
product-B/project-B-0
product-B/project-B-1
product-B/project-B-3
...
//продукт N состоит из M проектов и как А и Б в той или иной мере использует modul`и и external lib`ы
product-N/project-N-0
product-N/project-N-1
...
product-N/project-N-M
сейчас всё это как лежит на диске, так и запихнуто в один репозитарий Меркуриала
а как правильнее сделать?
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Re[5]: Организация репозитария для shared компонентов
K>ну ладно конкретный пример для vc++:
K>имеем на диске такие папки:
K>// внешние либы от сторонник разработчиков. используются везде. обновляются очень редко K>externals/lib-0 K>externals/lib-1 K>externals/lib-2
K>// модули — проекты общие для всех продуктов, но в тоже время часто редактируются в процессе девелопмента продуктов K>module-0 K>module-1 K>module-2
K> ...
K>//продукт А состоит из двух проектов(эти проекты используются только этим продуктом и никаких не реюзятся), эти проекты референсятся/используют/линкуют часть modules и часть external lib K>product-A/project-A-0 K>product-A/project-A-1
K> ...
K>сейчас всё это как лежит на диске, так и запихнуто в один репозитарий Меркуриала
Модули и внешние либы (назовем их внешними зависимостями) — разложить в разные репо Ртутного. Продукты — так же каждого в свой репо (каждый проект внутри отделять поначалу не стОит).
Для каждого проекта написать скриптик, который дергает нужные репы внешних зависимостей, буквально несколько команд будет для клона репов нужных.
Чтобы иметь возможность обеспечивать обратную совместимость зависимостей и юзающих их продуктов — надо бы на срезы этих зависимостей вешать метки по мере выпуска и вытягивать их потом именно по этим меткам.
Здравствуйте, Aquary, Вы писали:
A>Модули и внешние либы (назовем их внешними зависимостями) — разложить в разные репо Ртутного. Продукты — так же каждого в свой репо (каждый проект внутри отделять поначалу не стОит). A>Для каждого проекта написать скриптик, который дергает нужные репы внешних зависимостей, буквально несколько команд будет для клона репов нужных. A>Чтобы иметь возможность обеспечивать обратную совместимость зависимостей и юзающих их продуктов — надо бы на срезы этих зависимостей вешать метки по мере выпуска и вытягивать их потом именно по этим меткам.
A>Если вкратце — то вот так.
а имеет смысл вместо скриптов и меток(в принципе мне рассказали как лучше всего это делать: записывать ревизию в последнюю цифру версии проекта, но в студии это придется делать руками и легко ошибиться)
так вот имееет ли смысл subrepos использовать для модулей и внешних зависимостей?
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Re[7]: Организация репозитария для shared компонентов
Здравствуйте, Kingofastellarwar, Вы писали:
K>так вот имееет ли смысл subrepos использовать для модулей и внешних зависимостей?
Я с ними не работал, не скажу. Но по описанию — похожи на то, что надо. Однако, метки для мэппинга разных продуктов и либ между собой — думаю всё равно будут нужны, но тут уже тебе виднее будет на проекте, когда и зачем.
