Я создал зеркало SObjectizer на GitHub. Зачем? Чтобы был ответ на первый же вопрос, который возникает при анонсе очередного выпуска :) Однако зеркало есть зеркало и оно пока никак не влияет на существующий и устоявшийся процесс разработки. Цель: упростить доступ широкому кругу заинтересованных разработчиков к проекту.
Современные реалии таковы, что умение разработчика отличить GitHub от git - это критерий высокой квалификации, ну, а освоить незнакомый но полезный инструмент - очень высокой, короче народ предпочитает пользоваться привычными инструментами, куда SF не входит уже с десяток лет. В результате старперы, которые в молодости легко могли метнуться в другой город за 20 дискетками с дистрибутивом нового Борланд C++ и полночи слушать как дисковод надрывно пытается с пятого прохода прочитать слегка попорченный сектор во флопповоде, пытаясь установить Borland C++ 3 с половиной, ну никак не понимают, почему современная молодежь не осиливает освоить 4 команды svn (checkout, update, status, commit), при том, что всю идеологию svn для такой работы осиливать не нужно (главное, чтобы про branch и merge знал лидер проекта). Но, это я отвлекся.
Работает так (точнее, пока вообще никак не работает, но планируется). Сейчас я сделал копию репозитория для so_5 в git со всей историей изменений, в том числе и при копировании папок и объединении изменений (merge) разных веток. Авторство тоже сохранено. Сделано это было с помощью git-svn. Никаких других проектов из вашего SVN репозитория в git быть не должно. Далее я не нашел в git возможности, которую предоставляет externals, а именно взять не весь другой проект (репозиторий), а лишь папку или один файл из него (ибо ветки (branch) в git устроены совсем не так архаично, как CVS-SVN, на файловую систему отображается лишь одна ветка, а не весь репозиторий), поэтому я просто внес timertt, utest_helper_1 и various_helpers_1 в основной проект. На текущем этапа нужно понять, нужен ли кому-либо git репозиторий для SO, а эти подпроекты меняются очень редко, поэтому на данном этапе приемлемое решение. Сейчас на GitHub отображается branch/5.5, т.е. devel ветка. Можно сделать и больше, надо только понять, какие ветки нужны.
Далее я планирую при внесении изменений в основной репозиторий копировать их в репозиторий на GitHub. Делаться это будет так: при коммите на SF мне приходит письмо об изменении, которое будет обрабатывается скриптом делающим git svn fetch, в результате которого изменения попадут в отдельную ветку моего локального git репозитория. Далее я делаю merge этих изменений в master ветку и push на GitHub. Первое время я буду это делать вручную - нужно убедиться, что все будет работать так, как я ожидаю. Далее изменения в svn репозитории будут отображаться на GitHub в реалтайме (мне приходит письмо с уведомлением про push в SVN, у меня отрабатывает скрипт git svn fetch; git merge; git push и если нет ошибок, то данные на GitHub).
Причина по которой я не могу без merge отображать ветки svn в git (на самом деле могу, но толку от этого не будет) в том, что я уже внес изменения, которых нет в svn (externals включены в репозиторий so_5, написан README.md, который отображается на главной странице SObjectizer на GitHub). В результате на GitHub отображается своя отдельная ветка, в которую merge'ться все изменения, которые происходят в SVN (точнее будут merge'ться).
Существующее решение временное, его можно будет улучшить, но текущая цель - понять, насколько оно надо, кому и для каких целей.
Если есть вопросы или предложения, что улучшить пишите сюда или на почту
san@masterspline.net
Леша.
Last edit: Yauheni Akhotnikau 2015-04-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
По опыту, внесение более-менее серьезного изменения в dev-ветку -- это от десятка до сотни коммитов (например, разработка лимитов потребовала чуть меньше 60 коммитов). Правильно я понимаю, что лучше такие изменения выполнять в отдельной ветке, которая затем мержится с branches/so_5/5.5? В результате тебе на GitHub-е придется делать всего один-два fetch/merge/push, а не несколько десятков.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-03-16
Не совсем понял о чем ты, но ответ - нет. Зеркало на GitHub никак не должно влиять на разработку (на самом деле его влияние не будет заметно). Я планирую сделать на GitHub копии (или почти копии) веток в SVN. Т.е. веди разработку и коммить как тебе удобнее, а на GitHub просто появятся эти же изменения с небольшой задержкой. Более того fetch->merge->push будут делаться полностью автоматом, т.е. работать будет железка, в результате их количество не имеет значения. Отдельные ветки разработки я тоже планирую копировать на GitHub (но, пока не знаю, как это сделать совсем автоматом (т.е. надежно и без ручного вмешательства) пока не знаю (не изучал серьезно).
Таким образом, вручную будут лишь обрабатываться ошибки работы скрипта (и, возможно, создания веток типа 5.5.4--internal-stats, которые делаются одна-две на версию, т.е. на 3-4 месяца).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Лёша, а как ты видишь себе прием пулл-реквестов на GH и "вливание" их в Svn-новский репозиторий на SF?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-03-16
Если несерьезно, то "надо еще дожить".
А если серьезно, то вопрос имеет смысл, только если ты всю жизнь работал с централизованной системой контроля версий в конторе с небольшой командой... :) В Linux, например, патчи принимают в виде писем в рассылку (и какая у тебя система контроля версий никого не интересует совсем, просто с помощью git проще подготавливать патчи для текущего состояния дерева исходников).
Я это к тому, что процесс будет выглядеть не как прямое внесение изменений (как, например, ты мне дал доступ и я туда делаю commit) после чего ты делаешь (или не делаешь review), а как-то по другому, и то что pull request подготовлен в git, а не svn лишь добавит еще один шаг в внесению этого патча в основной репозиторий.
Я себе это представлял как "Женя, тут какой-то pull request, скажи, нужен ли он", но лучше будет вариант, что я внесу эти изменения в отдельную ветку svn, а ты будешь дальше сам разбираться (ветки я удалять уже умею и понимаю, что такое ветка в SVN и насколько она сильно отличается от ветки в git).
В общем, review делаю не я, потому я могу лишь упростить задачу (как эти изменения попадут в svn), но какие решаю все равно не я.
Из сложностей я тут вижу пока одну - в git есть автор и коммитер, в svn - это одно лицо, поэтому нужно будет в длинной части комментария к коммиту указывать автора.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Когда поступает pull-request для git:/dev, он обрабатывается, проверяется результат. Возможно, что-то дорабатывается. Итог вливается в svn:/branches/so_5/5.5-git-dev.
Затем svn:/branches/so_5/5.5-git-dev мержится с svn:/branches/so_5/5.5. Новая версия из svn:/branches/so_5/5.5 попадает в git:/master.
После чего изменения из git:/master мержатся с get:/dev для того, чтобы эти две ветки не расползались.
Хотя все это выглдит пока каким-то оверкиллом.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-03-16
Все верно до вот этого предложения:
После чего изменения из git:/master мержатся с get:/dev для того, чтобы эти две ветки не расползались.
git:dev просто удаляется, изменения, пройдя через svn уже попали в master.
Хотя все это выглдит пока каким-то оверкиллом.
Потому что никто не использует git и svn для разработки одновременно. Да и вообще, тебе про это знать не нужно, это моя забота, как их согласовать.
P.S. IMHO по мне так одновременно довольно хорошо освоить git и svn это уже оверкилл (т.е. на уровне серьезнее, чем checkout->update->status->commit).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
git:dev просто удаляется, изменения, пройдя через svn уже попали в master.
Ok, вроде понял. git:dev делается для принятия pull request-а и удаляется после того, как правки попадают в master.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-03-16
В общих чертах так.
А в деталях в какую ветку будет направлен pull request решает его автор (у тебя, например, могут быть отдельные ветки для версии с поддержкой C++11 и C++14 и в одной из них кто-то нашел ошибку, которую исправил и прислал тебе патч в виде pull request), а вот куда его применять - владелец репозитория. В нашем же случае pull request нужно будет превратить в patch. А дальше основным репозиторием, куда накладываются изменения будет svn, вот в него-то и будут направляться патчи (в отдельную ветку, разумеется).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ну и абстрактный, пока вопрос. Допустим, GH-зеркало заработает и будет использоваться. Допустим, нам нужно будет обновить utest_helpers (а реально нужно). Допустим, нам нужно будет начать работы над веткой 5.6, но какое-то время поддерживать и ветку 5.5. Допустим, мы реанимируем один из подпроектов (первый кандидат so_sysconf) или начнем новый подпроект (актуальность нового "родного" транспорта становится все выше и выше).
Как все это будет решаться в твоем представлении? Скажем, в нормальных условиях, когда нет никаких граблей/проблем и все идет так, как тебе хочется.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-03-16
Допустим, нам нужно будет обновить utest_helpers (а реально нужно).
Сейчас я ручками внесу изменения в основной репозиторий. Но, думаю я придумаю что-то получше.
Допустим, нам нужно будет начать работы над веткой 5.6, но какое-то время поддерживать и ветку 5.5.
Ветки в git будут абсолютно так же себя вести, как и в svn (пока я не увидел никаких сложностей). Просто для начала я сделал одну ветку master, которая копирует branches/so_5/5.5. Сделано это для того, чтобы проверить, как вся схема будет себя вести и потому что мне наиболее понятно, что в 5.5 происходит.
Допустим, мы реанимируем один из подпроектов (первый кандидат so_sysconf) или начнем новый подпроект (актуальность нового "родного" транспорта становится все выше и выше).
Как сделать привычную и удобную работу с подпроектами я пока не знаю. Это первоочередная цель.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Как сделать привычную и удобную работу с подпроектами я пока не знаю. Это первоочередная цель.
Так может имеет смысл завести на GH специального юзверя so5mirror и под ним создать не один репозиторий, а несколько. Например, timertt, utest_helpers, so5core и т.д. После чего внутри этих репозиториев ссылки на подпроекты оформлять через git submodules?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-03-16
Примерно так я и планирую. Только специальны пользователь не нужен. И репозитории, на которые будут ссылаться submodules нужно сделать непростыми.
Submodules берет всю рабочую директорию репозитория целиком и кладет в указанную папку проекта. У тебя сейчас берутся подпапки рабочей директории, а не вся папка. У меня есть идея, как это сэмулировать, но нужно ее проверить.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-03-16
Нашел способ импортировать в виде submodule части рабочей папки проекта. Точнее из самого импортируемого подпроекта в виде отдельной ветки экспортирую нужную часть.
Теперь timertt, utest_helper_1 и various_helpers_1 заведены отдельными репозиториями, в каждом создана ветка export и именно она импортируется в виде submodule в репозитории SObjectizer. При изменении подпроектов, нужно будет сделать merge в ветку export.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ну что ж, остается посмотреть, как все это будет работать.
Есть у меня ощущение, что какой-то семиколесный велосипед получается. Но, надеюсь, что ошибаюсь.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-03-16
Про копирование вики на GitHub пока не думал.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-03-16
По ходу работы над git репозиторием нашел одну непреодолимую неприятность. Не получится сделать ветку в git совсем полной копией ветки в svn. Для submodule не достаточно одного только файла .gitmodules, требуется что-то еще (т.е. недостаточно добавить .gitmodules в svn репозиторий, чтобы при попадании его в гит тот начал работать с submodule). В результате в git репозитории будут какие-то внутренние невидимые отличия (не в рабочих файлах), поэтому ветка из svn (без submodule) будет отдельно соответствующей ветки git. А это значит, что постоянно придется делать объединение изменений (merge) и журнал изменений из svn ветки в виде
Привет всем.
Я создал зеркало SObjectizer на GitHub. Зачем? Чтобы был ответ на первый же вопрос, который возникает при анонсе очередного выпуска :) Однако зеркало есть зеркало и оно пока никак не влияет на существующий и устоявшийся процесс разработки. Цель: упростить доступ широкому кругу заинтересованных разработчиков к проекту.
Современные реалии таковы, что умение разработчика отличить GitHub от git - это критерий высокой квалификации, ну, а освоить незнакомый но полезный инструмент - очень высокой, короче народ предпочитает пользоваться привычными инструментами, куда SF не входит уже с десяток лет. В результате старперы, которые в молодости легко могли метнуться в другой город за 20 дискетками с дистрибутивом нового Борланд C++ и полночи слушать как дисковод надрывно пытается с пятого прохода прочитать слегка попорченный сектор во флопповоде, пытаясь установить Borland C++ 3 с половиной, ну никак не понимают, почему современная молодежь не осиливает освоить 4 команды svn (checkout, update, status, commit), при том, что всю идеологию svn для такой работы осиливать не нужно (главное, чтобы про branch и merge знал лидер проекта). Но, это я отвлекся.
Работает так (точнее, пока вообще никак не работает, но планируется). Сейчас я сделал копию репозитория для so_5 в git со всей историей изменений, в том числе и при копировании папок и объединении изменений (merge) разных веток. Авторство тоже сохранено. Сделано это было с помощью git-svn. Никаких других проектов из вашего SVN репозитория в git быть не должно. Далее я не нашел в git возможности, которую предоставляет externals, а именно взять не весь другой проект (репозиторий), а лишь папку или один файл из него (ибо ветки (branch) в git устроены совсем не так архаично, как CVS-SVN, на файловую систему отображается лишь одна ветка, а не весь репозиторий), поэтому я просто внес timertt, utest_helper_1 и various_helpers_1 в основной проект. На текущем этапа нужно понять, нужен ли кому-либо git репозиторий для SO, а эти подпроекты меняются очень редко, поэтому на данном этапе приемлемое решение. Сейчас на GitHub отображается branch/5.5, т.е. devel ветка. Можно сделать и больше, надо только понять, какие ветки нужны.
Далее я планирую при внесении изменений в основной репозиторий копировать их в репозиторий на GitHub. Делаться это будет так: при коммите на SF мне приходит письмо об изменении, которое будет обрабатывается скриптом делающим git svn fetch, в результате которого изменения попадут в отдельную ветку моего локального git репозитория. Далее я делаю merge этих изменений в master ветку и push на GitHub. Первое время я буду это делать вручную - нужно убедиться, что все будет работать так, как я ожидаю. Далее изменения в svn репозитории будут отображаться на GitHub в реалтайме (мне приходит письмо с уведомлением про push в SVN, у меня отрабатывает скрипт git svn fetch; git merge; git push и если нет ошибок, то данные на GitHub).
Причина по которой я не могу без merge отображать ветки svn в git (на самом деле могу, но толку от этого не будет) в том, что я уже внес изменения, которых нет в svn (externals включены в репозиторий so_5, написан README.md, который отображается на главной странице SObjectizer на GitHub). В результате на GitHub отображается своя отдельная ветка, в которую merge'ться все изменения, которые происходят в SVN (точнее будут merge'ться).
Существующее решение временное, его можно будет улучшить, но текущая цель - понять, насколько оно надо, кому и для каких целей.
Если есть вопросы или предложения, что улучшить пишите сюда или на почту
san@masterspline.net
Леша.
Last edit: Yauheni Akhotnikau 2015-04-07
Во-первых, это круто! Огромное спасибо за проделанную работу!
Во-вторых, мотивация понятна. Не думаю, что имеет смысл обсуждать цель организации зеркала на GitHub.
Поэтому предлагаю устроить обсуждение по конкретным вопросам в режиме -- один вопрос по GH-зеркалу -- один ответ на первое сообщение в этой теме.
По опыту, внесение более-менее серьезного изменения в dev-ветку -- это от десятка до сотни коммитов (например, разработка лимитов потребовала чуть меньше 60 коммитов). Правильно я понимаю, что лучше такие изменения выполнять в отдельной ветке, которая затем мержится с branches/so_5/5.5? В результате тебе на GitHub-е придется делать всего один-два fetch/merge/push, а не несколько десятков.
Не совсем понял о чем ты, но ответ - нет. Зеркало на GitHub никак не должно влиять на разработку (на самом деле его влияние не будет заметно). Я планирую сделать на GitHub копии (или почти копии) веток в SVN. Т.е. веди разработку и коммить как тебе удобнее, а на GitHub просто появятся эти же изменения с небольшой задержкой. Более того fetch->merge->push будут делаться полностью автоматом, т.е. работать будет железка, в результате их количество не имеет значения. Отдельные ветки разработки я тоже планирую копировать на GitHub (но, пока не знаю, как это сделать совсем автоматом (т.е. надежно и без ручного вмешательства) пока не знаю (не изучал серьезно).
Таким образом, вручную будут лишь обрабатываться ошибки работы скрипта (и, возможно, создания веток типа 5.5.4--internal-stats, которые делаются одна-две на версию, т.е. на 3-4 месяца).
Лёша, а как ты видишь себе прием пулл-реквестов на GH и "вливание" их в Svn-новский репозиторий на SF?
Если несерьезно, то "надо еще дожить".
А если серьезно, то вопрос имеет смысл, только если ты всю жизнь работал с централизованной системой контроля версий в конторе с небольшой командой... :) В Linux, например, патчи принимают в виде писем в рассылку (и какая у тебя система контроля версий никого не интересует совсем, просто с помощью git проще подготавливать патчи для текущего состояния дерева исходников).
Я это к тому, что процесс будет выглядеть не как прямое внесение изменений (как, например, ты мне дал доступ и я туда делаю commit) после чего ты делаешь (или не делаешь review), а как-то по другому, и то что pull request подготовлен в git, а не svn лишь добавит еще один шаг в внесению этого патча в основной репозиторий.
Я себе это представлял как "Женя, тут какой-то pull request, скажи, нужен ли он", но лучше будет вариант, что я внесу эти изменения в отдельную ветку svn, а ты будешь дальше сам разбираться (ветки я удалять уже умею и понимаю, что такое ветка в SVN и насколько она сильно отличается от ветки в git).
В общем, review делаю не я, потому я могу лишь упростить задачу (как эти изменения попадут в svn), но какие решаю все равно не я.
Из сложностей я тут вижу пока одну - в git есть автор и коммитер, в svn - это одно лицо, поэтому нужно будет в длинной части комментария к коммиту указывать автора.
Но ведь можно, например, иметь в git две ветки -- master и dev.
Из Svn в GitHub идет отображение в master. А pull-request-ы принимаются для dev-а.
При этом можно иметь такую картинку:
svn:/branches/so_5/5.5 --> git:/master
git:/dev --> svn:/branches/so_5/5.5-git-dev
Когда поступает pull-request для git:/dev, он обрабатывается, проверяется результат. Возможно, что-то дорабатывается. Итог вливается в svn:/branches/so_5/5.5-git-dev.
Затем svn:/branches/so_5/5.5-git-dev мержится с svn:/branches/so_5/5.5. Новая версия из svn:/branches/so_5/5.5 попадает в git:/master.
После чего изменения из git:/master мержатся с get:/dev для того, чтобы эти две ветки не расползались.
Хотя все это выглдит пока каким-то оверкиллом.
Все верно до вот этого предложения:
git:dev просто удаляется, изменения, пройдя через svn уже попали в master.
Потому что никто не использует git и svn для разработки одновременно. Да и вообще, тебе про это знать не нужно, это моя забота, как их согласовать.
P.S. IMHO по мне так одновременно довольно хорошо освоить git и svn это уже оверкилл (т.е. на уровне серьезнее, чем checkout->update->status->commit).
Ok, вроде понял. git:dev делается для принятия pull request-а и удаляется после того, как правки попадают в master.
В общих чертах так.
А в деталях в какую ветку будет направлен pull request решает его автор (у тебя, например, могут быть отдельные ветки для версии с поддержкой C++11 и C++14 и в одной из них кто-то нашел ошибку, которую исправил и прислал тебе патч в виде pull request), а вот куда его применять - владелец репозитория. В нашем же случае pull request нужно будет превратить в patch. А дальше основным репозиторием, куда накладываются изменения будет svn, вот в него-то и будут направляться патчи (в отдельную ветку, разумеется).
Ну и абстрактный, пока вопрос. Допустим, GH-зеркало заработает и будет использоваться. Допустим, нам нужно будет обновить utest_helpers (а реально нужно). Допустим, нам нужно будет начать работы над веткой 5.6, но какое-то время поддерживать и ветку 5.5. Допустим, мы реанимируем один из подпроектов (первый кандидат so_sysconf) или начнем новый подпроект (актуальность нового "родного" транспорта становится все выше и выше).
Как все это будет решаться в твоем представлении? Скажем, в нормальных условиях, когда нет никаких граблей/проблем и все идет так, как тебе хочется.
Сейчас я ручками внесу изменения в основной репозиторий. Но, думаю я придумаю что-то получше.
Ветки в git будут абсолютно так же себя вести, как и в svn (пока я не увидел никаких сложностей). Просто для начала я сделал одну ветку master, которая копирует branches/so_5/5.5. Сделано это для того, чтобы проверить, как вся схема будет себя вести и потому что мне наиболее понятно, что в 5.5 происходит.
Как сделать привычную и удобную работу с подпроектами я пока не знаю. Это первоочередная цель.
Так может имеет смысл завести на GH специального юзверя so5mirror и под ним создать не один репозиторий, а несколько. Например, timertt, utest_helpers, so5core и т.д. После чего внутри этих репозиториев ссылки на подпроекты оформлять через git submodules?
Примерно так я и планирую. Только специальны пользователь не нужен. И репозитории, на которые будут ссылаться submodules нужно сделать непростыми.
Submodules берет всю рабочую директорию репозитория целиком и кладет в указанную папку проекта. У тебя сейчас берутся подпапки рабочей директории, а не вся папка. У меня есть идея, как это сэмулировать, но нужно ее проверить.
Нашел способ импортировать в виде submodule части рабочей папки проекта. Точнее из самого импортируемого подпроекта в виде отдельной ветки экспортирую нужную часть.
Теперь timertt, utest_helper_1 и various_helpers_1 заведены отдельными репозиториями, в каждом создана ветка export и именно она импортируется в виде submodule в репозитории SObjectizer. При изменении подпроектов, нужно будет сделать merge в ветку export.
Ну что ж, остается посмотреть, как все это будет работать.
Есть у меня ощущение, что какой-то семиколесный велосипед получается. Но, надеюсь, что ошибаюсь.
Про копирование вики на GitHub пока не думал.
По ходу работы над git репозиторием нашел одну непреодолимую неприятность. Не получится сделать ветку в git совсем полной копией ветки в svn. Для submodule не достаточно одного только файла .gitmodules, требуется что-то еще (т.е. недостаточно добавить .gitmodules в svn репозиторий, чтобы при попадании его в гит тот начал работать с submodule). В результате в git репозитории будут какие-то внутренние невидимые отличия (не в рабочих файлах), поэтому ветка из svn (без submodule) будет отдельно соответствующей ветки git. А это значит, что постоянно придется делать объединение изменений (merge) и журнал изменений из svn ветки в виде
change 1 -> update 1 -> fix 1 -> ... превратится в
change 1 -> merge with svn branch -> update 1 -> merge with svn branch -> fix 1 -> merge with svn branch -> ...
Не очень аккуратно в общем.