LINUX.ORG.RU

Хочется организовать процесс работы над проектом правильно

 ,


0

2

Есть численная модель, состоящая из большого числа модулей (цинк). Каждый участник проекта ставит численные эксперименты со своим набором модулей, в зависимости от задачи. Сейчас всё управляется с помощью CVS. Репозиторий представляет из себя долбаную кашу из тысяч веток, которые никогда не сливаются, и квадрильёна тагов, которые больше никому не нужны. Хочется уговорить коллег перелезть на более прогрессивную систему управления версиями. Например, по вот этой замечательной схеме. Возникает вопрос, как организовать тематические ветки, в которых набор модулей отличается от набора модулей в master и develop? Про подмодули и cherry-pick читал. Это будет полезно, но проблему полностью не решает. После трёхдневного гугления, придумал следующий способ.

Допустим, у меня есть репозиторий с тематической веткой, в которой подмножество модулей из master плюс пара моих модулей, которых в master нет. Выходит релиз, надо обновиться, но тащить всё из master мы не хотим. Делаем следующее

git checkout master
git pull origin
git checkout -b new_release topic_branch
git checkout master $path_to_my_modules
git checkout topic_branch
git merge new_release
git branch -d new_release

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

git checkout develop
git pull origin
git branch update_branch
git checkout topic_branch $path_to_my_modules
git checkout develop
git merge update_branch
git branch -d update_branch
git push origin

Опыта групповой работы с git не имею, ничего лучше придумать не могу, протестировать workflow тоже не могу, т.к. никто из коллег не знает, что такое git. Специалисты по git, оно вобще работать будет? Может есть более простой способ достичь такого же результата?

★★☆

То, что ты описал, похоже на гребаный SVN (с CVS не работал, но думаю, что там так же). Не надо пытаться из git сделать cvs, это точно не будет работать лучше, чем было.

annulen ★★★★★
()

Ересь, собственно, вот в этом:

git checkout master $path_to_my_modules
...
git checkout topic_branch $path_to_my_modules

Частичный чекаут подкаталога может быть естественным в svn (cvs?), где каждый подкаталог - как отдельный репозиторий, в гите такой подход приведет к хаосу и потере истории файлов.

annulen ★★★★★
()

Есть численная модель

Если это характеристика задачи, то рекомендую напрячься и сделать модуль для boinc

ziemin ★★
()
Ответ на: комментарий от annulen

Частичный чекаут подкаталога может быть естественным в svn (cvs?), где каждый подкаталог - как отдельный репозиторий, в гите такой подход приведет к хаосу и потере истории файлов.

Ай, блин, commit во временную ветку-то я забыл. По поводу хаоса, как-то не вижу, в чём он?

yvv ★★☆
() автор топика
Ответ на: комментарий от ziemin

Причём тут boinc? У меня вычислительных ресурсов хоть задницей жри.

yvv ★★☆
() автор топика
Ответ на: комментарий от yvv

Потому что там куча модулей, которые для моего эксперимента не нужны.

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

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

mashina ★★★★★
()
Ответ на: комментарий от annulen

В svn тоже будет ж. Тогда уж externals переключать, чем как у ТС.

gh0stwizard ★★★★★
()
Ответ на: комментарий от annulen

Не надо пытаться из git сделать cvs, это точно не будет работать лучше, чем было.

Дело в том, что этот cvs задолбал уже. Но некоторые фичи из него нужны для проекта. Нам необходимо иметь возможность брать подмножество центрального репозитория.

yvv ★★☆
() автор топика

Можно каждый модуль загнать в отдельный бранч (то есть натурально, в каждом бранче независимая история, по типу gh-pages или арчевской репы) и для игрищ намерживать нужный набор.

anonymous
()
Ответ на: комментарий от mashina

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

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

Это всё будет сложнее, чем приклеить tag в cvs. Никто на такое не согласится.

yvv ★★☆
() автор топика

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

bvn13 ★★★★★
()
Ответ на: комментарий от bvn13

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

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

yvv ★★☆
() автор топика
Ответ на: комментарий от yvv

Это всё будет сложнее, чем приклеить tag в cvs. Никто на такое не согласится.

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

mashina ★★★★★
()
Ответ на: комментарий от mashina

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

Вот, пытаюсь бороться с инертностью. Ок, твой вариант попробую предложить протестировать.

yvv ★★☆
() автор топика
Ответ на: комментарий от yvv

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

Но кто-то же должен это знать. Вот этого кто-то и спросить.

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

alexku
()
Ответ на: комментарий от alexku

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

Я тоже так думал сначала. Но оказалось, что это не совсем так. Хочу склонить коллег в более правильную сторону. Заодно и должность повыше получить. Сам всё мержить хочу. Чую, так лучше будет, но пока не решил как именно.

yvv ★★☆
() автор топика
Ответ на: комментарий от tailgunner

Тебе не git нужен, а учебник по организации разработки.

Да! Ссылка где?

Вот я нашёл одну http://nvie.com/posts/a-successful-git-branching-model Очень хорошая организация, я считаю. Как бы это реализовать?

yvv ★★☆
() автор топика
Последнее исправление: yvv (всего исправлений: 1)
Ответ на: комментарий от yvv

Мне самому это давно не нужно, поэтому новых ссылок нет. Я постигал основы по http://www.google.ru/url?q=http://bcf.redirectme.net/bcfHttpRepository/docume...

Да, и я бы не советовал впаривать git людям, которые толком не освоили CVS.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Мне самому это давно не нужно, поэтому новых ссылок нет. Я постигал основы по http://www.google.ru/url?q=http://bcf.redirectme.net/bcfHttpRepository/docume...

Да, и я бы не советовал впаривать git людям, которые толком не освоили CVS.

За ссылку спасибо. Людей, которые не освоили CVS у нас навалом. Физики всякие, химики, и прочие ... коллеги. Для них, собственно, и стараюсь. Человек должен иметь возможность забодяжить научный эксперимент, который порвёт материю вселенной, не вдаваясь в эти ваши мелкие детали про git и CVS. Но я пока что не решил, а что же лучше, git или продолжать тухнуть на CVS?

yvv ★★☆
() автор топика
Последнее исправление: yvv (всего исправлений: 1)

советую обратить внимание на git subtree - «подмодули» вчерашний день и на фоне subtree выглядит неудобноым примитивом.

Для освоения subtree достаточно разобраться в 1-3 этапа одному члену рабочей группы - остальные могут продолжат работать как обычно. «Поддерево» прозрачно. Пока не выполнено расщепление явно поддерева в рабочей копии репы - все работает как обычно, но тот, у кого это расщепление выполнено, может сливать изменения и словом вести workflow над поддеревом самым обычным образом, как с основным деревом. И в то-же время поддерево в проекте локальной репы выглядит прозрачно т.е. так-же заурядно как и остальные объекты.

Для subtree есть плагин - он внедряется через хук и становится частью набора команд гита.

Так-же для тематических веток использовать тэги.

swwwfactory ★★
()
Последнее исправление: swwwfactory (всего исправлений: 1)

Для начала предлагаю поглядеть на repo. Он позволяет, грубо говоря, устроить CVS-like помойку из произвольного набора git-репозиториев :)

Да, написан был на питоне, tailgunner будет доволен ;)

AlexM ★★★★★
()
Ответ на: комментарий от swwwfactory

Кстати, наверное, да.

Единственный момент, который [был] неудобен с subtree-merge - это трудность обратных коммитов, то есть, нельзя править исходники включённых модулей прямо в общем дереве.

AlexM ★★★★★
()

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

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

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

dmitry_malikov ★★
()
Ответ на: комментарий от dmitry_malikov

а простолюдинам проще иметь дело с линейной историей.

Это, кстати, вопрос привычки. Поначалу, конечно, да, через месяц использования в рабочем режиме люди перестают обращать на это внимание.

AlexM ★★★★★
()
Ответ на: комментарий от AlexM

Единственный момент, который [был] неудобен с subtree-merge - это трудность обратных коммитов, то есть, нельзя править исходники включённых модулей прямо в общем дереве.

из проекта пушить через subtree push в отдельную ветку отдельного локального репозитария - потом ее смерджить с общей веткой, а обратно в проект через pull subtree...

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

swwwfactory ★★
()
Ответ на: комментарий от swwwfactory

из проекта пушить через subtree push в отдельную ветку отдельного локального репозитария...

Это-то понятно. Но именно это я указал как «сложность». Впрочем, если приучиться... Правда, есть ещё и вот какой момент: поддержка всего этого хозяйства в IDE и других не-CLI-средств. Модули, расположенные в разных репозиториях, хорошо ложатся на схему «главный проект/подпроекты», обычную для IDE, а вот с subtree есть серьёзные /трудности/.

Впрочем, конечно, это дело привычки и самоорганизации.

AlexM ★★★★★
()

Например, по вот этой замечательной схеме.

Та замечательная схема описывает общепринятые и средние по палате методы работы с git которые впоследствии были оформлены в виде инструмента под названием git-flow который упрощает работу согласно описанным выше методикам.

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

На каждого участника по своей ветке „для всех, даром, и пусть никто не уйдет обиженный!“ ©

init_6 ★★★★★
()
Ответ на: комментарий от AlexM

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

dmitry_malikov ★★
()
Ответ на: комментарий от yvv

там куча модулей, которые для моего эксперимента не нужны.

Так не используй их. Мне кажется, у вас серьёзные проблемы с приложением. Лучше скооперируйтесь и причешите. Потом самим же будет проще.

true_admin ★★★★★
()
Ответ на: комментарий от dmitry_malikov

Уважающий себя человек всегда сделает ребэйз или мёрж со сквошем, чем будет плодить очередной мёрж-коммит.

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

tailgunner ★★★★★
()
Ответ на: комментарий от true_admin

Так не используй их.

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

П.С. сейчас проверил, модуль верхнего уровня имеет 2000 тэгов. Мой модуль 350 тэгов. :)

yvv ★★☆
() автор топика
Ответ на: комментарий от yvv

тэг в котором содержится только то, что нужно для конкретной задачи, ничего лишнего

Мне кажется, это надо решать не средствами vcs, а системой сборки которая спросит что нужно юзеру и отрубит всё лишнее. В любом случае, тэги при таком использовании это уж слишком негибко, что подтвреждается тем п*цом что у вас творится.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Мне кажется, это надо решать не средствами vcs, а системой сборки которая спросит что нужно юзеру и отрубит всё лишнее.

Такой подход обсуждался на ранних версиях, но как-то не получил признания. Мало того, в других компаниях, которые делают GCM он вполне успешно используется. Для каждой задачи создаётся драйвер скрипт, который собирает всё что нужно. Каждый эксперимент всё равно надо метить тэгом, но это уже не проблема.

Ок, попробую поставить этот вопрос на повестку дня снова.

yvv ★★☆
() автор топика
Ответ на: комментарий от yvv

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

true_admin ★★★★★
()
Ответ на: комментарий от tailgunner

Уж заклеймил так заклеймил ;)

Топик-стартеру: повторюсь, судя по описанию, Вам нужно что-то типа svn:externals. repo позволяет организовать его аналог, но на базе набора git'овых репозиториев, и в чём-то даже более продвинутый аналог.

Собственно, когда я ~5 лет назад утаскивал один достаточно развесистый проект, чуть менее чем полностью построенный на (виртуальных) CVS-модулях, то я рассматривал repo как вариант переезда без существенного изменения воркфлоу конечных пользователей. Но остановило то, что вся эта repo'шная машинерия - она слегка сбоку от остального git'ового хозяйства, что препятствует «прозрачному использованию» всего этого добра, например. из IDE.

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

AlexM ★★★★★
()
Ответ на: комментарий от dmitry_malikov

С радостью послушаю какое может быть переписывание истории

Да не вопрос: http://git-scm.com/book/ch6-4.html http://stackoverflow.com/questions/tagged/git-rewrite-history

иммутабельных гитовых объектов

Git-фанбой оказался еще и Haskell-фанбоем, какая неожиданность. Для полного комплекта ты еще должен работать похапе-кодером.

tailgunner ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.