Насколько я понял у нас стояло три проблемы мешающие переезду. Первая это svn externals. Вторая версии на основе номера svn ревизии. Третья подсветка кода.
Я сделал зеркало и постарался решить означенные проблемы.
Svn externals:
Не поддерживаются гитом, пришлось сделать для них гит репозитарии и подключить как submodules. Обновлять их придется вручную, но я не вижу в этом большой проблемы, обновляются они не так уж и часто. Причин билдить всегда с самой распоследней версией я не вижу.
Версии на основе номера ревизии:
Сделал макрос, аналогичный AssemblyVersionFromSVN. Отличие в том, что в гите нет сквозной нумерации ревизий. Зато есть способ посчитать количество ревизий от последнего тега. Соответственно мажорная/минорная версия тоже проставляется автоматом и не надо ее менять руками по куче файлов, ревизия же считается от нее, что тоже мне кажется более наглядным. Есть потенциальная дыра — два бранча могут получить одинаковый номер ревизии, но в каких сценариях это может помешать я не знаю. Вобщем релиз nemerle для .net 4 пойдет уже как 1.1 и проблем со сменой нумерации я не вижу.
Подсветка кода:
Сделал лексер для пигемнтов. К сожалению его чего-то не мерджат, тикет тут. Кто свободно болтает по английски, зайдте в их ирц и спросите что мешает. За время прошедшее с пулревеста они смерджили дофига чего, в том числе и какой-то язык новый. Просьба только аккуратно и вежливо, даже если они ненавидят nemerle.
Вобщем просьба потестить макрос и билд из репозитария (надо переключиться на бранч git-migration).
Здравствуйте, Ziaw, Вы писали:
Z>Я сделал зеркало и постарался решить означенные проблемы.
Z>Вобщем просьба потестить макрос и билд из репозитария (надо переключиться на бранч git-migration).
Да, после переключения на бранч надо еще инициализировать submodules: 'git submodule update --init'
Здравствуйте, Ziaw, Вы писали:
Z>Насколько я понял у нас стояло три проблемы мешающие переезду. Первая это svn externals. Вторая версии на основе номера svn ревизии. Третья подсветка кода.
Z>Я сделал зеркало и постарался решить означенные проблемы.
Здравствуйте, Ziaw, Вы писали:
Z>Насколько я понял у нас стояло три проблемы мешающие переезду. Первая это svn externals. Вторая версии на основе номера svn ревизии. Третья подсветка кода.
Z>Я сделал зеркало и постарался решить означенные проблемы.
Публикация git-svn метаданных — плохая идея, оно пока что не работает. Ну т.е. если кто-то склонирует этот репозиторий, а так же сделает git-svn clone из svn репозитория, то они не сойдутся, а у git-svn может сорвать башку.
Допустимо сделать так: прикрыть на запись svn, сделать клон, как вышеприведённый, как-нибудь через git-filter-branch сломать строчку git-svn-id, чтобы просто знать соответствие со старыми версиями, "Commit was imported from svn r12345" или как-то так. Или просто всех предупредить о грабле.
Z>Svn externals: Z>Не поддерживаются гитом, пришлось сделать для них гит репозитарии и подключить как submodules. Обновлять их придется вручную, но я не вижу в этом большой проблемы, обновляются они не так уж и часто. Причин билдить всегда с самой распоследней версией я не вижу.
В недалёком будущем вполне может стать возможным обойтись без промежуточного репозитория. Но и так вполне даже хорошо.
Z>Версии на основе номера ревизии: Z>Сделал макрос, аналогичный AssemblyVersionFromSVN. Отличие в том, что в гите нет сквозной нумерации ревизий. Зато есть способ посчитать количество ревизий от последнего тега. Соответственно мажорная/минорная версия тоже проставляется автоматом и не надо ее менять руками по куче файлов, ревизия же считается от нее, что тоже мне кажется более наглядным. Есть потенциальная дыра — два бранча могут получить одинаковый номер ревизии, но в каких сценариях это может помешать я не знаю. Вобщем релиз nemerle для .net 4 пойдет уже как 1.1 и проблем со сменой нумерации я не вижу.
Я не очень понимаю этой хренотени, нафига собственно? О чём эта возрастающая цифра говорит? Чтобы различать билды между собой есть sha1 коммита, можно засосать туда же и тэги, красивые релизные номера ест-но делаются руками 2.1.1 или 2.1.1-sha1 (или как я сказал, неявно через тэги). Можно даже положить скрипт make_next_release, делающий тег 2.1.n+1 на текущем коммите.
Здравствуйте, Ziaw, Вы писали:
Z>Насколько я понял у нас стояло три проблемы мешающие переезду. Первая это svn externals. Вторая версии на основе номера svn ревизии. Третья подсветка кода.
А что с базой issues? В гуглкоде были удобные автоматические перекрестные ссылки между комитами и багами — это все накроется?
Здравствуйте, Иванков Дмитрий, Вы писали:
Z>>Я сделал зеркало и постарался решить означенные проблемы. ИД>Публикация git-svn метаданных — плохая идея, оно пока что не работает.
Я ничего специально не публиковал, склонировал и пушнул.
ИД>Ну т.е. если кто-то склонирует этот репозиторий, а так же сделает git-svn clone из svn репозитория, то они не сойдутся, а у git-svn может сорвать башку.
Зачем кому-то так делать?
ИД>Допустимо сделать так: прикрыть на запись svn, сделать клон, как вышеприведённый, как-нибудь через git-filter-branch сломать строчку git-svn-id, чтобы просто знать соответствие со старыми версиями, "Commit was imported from svn r12345" или как-то так. Или просто всех предупредить о грабле.
Пока комиты идут только svn -> git, потом svn останется в режиме read-only для истории.
Z>>Версии на основе номера ревизии: ИД>Я не очень понимаю этой хренотени, нафига собственно? О чём эта возрастающая цифра говорит? Чтобы различать билды между собой есть sha1 коммита, можно засосать туда же и тэги, красивые релизные номера ест-но делаются руками 2.1.1 или 2.1.1-sha1 (или как я сказал, неявно через тэги). Можно даже положить скрипт make_next_release, делающий тег 2.1.n+1 на текущем коммите.
Не знаю, народ хочет. sha1 в AssemblyVersion не засунешь, остальные задачи макрос решает, нумерует на основании тэга и количества комитов после него.
Здравствуйте, Ziaw, Вы писали:
Z>Насколько я понял у нас стояло три проблемы мешающие переезду. Первая это svn externals. Вторая версии на основе номера svn ревизии. Третья подсветка кода.
Четвёртая — придумать нормальное имя организации. NemerleTeam как-то совсем не в попад. Назвать хотя бы nemerle. А лучше название nemerle оставить языку, а тому, что Влад называет платформой для создания компиляторов придумать название и назвать организацию таким именем.
Если нам не помогут, то мы тоже никого не пощадим.
ИД>>Публикация git-svn метаданных — плохая идея, оно пока что не работает. Z>Я ничего специально не публиковал, склонировал и пушнул.
Я про автоматически вставляемые git-svn-id в log messages, git-svn их читает при некоторых операциях.
ИД>>Ну т.е. если кто-то склонирует этот репозиторий, а так же сделает git-svn clone из svn репозитория, то они не сойдутся, а у git-svn может сорвать башку. Z>Зачем кому-то так делать?
Ну, например полетел магический репозиторий, из которого был push, или просто надо запушить ещё svn-а в git. А может не выйти.
Поэтому обновлять публичный git-svn клон в текущем состоянии git-svn — плохая идея.
Z>Пока комиты идут только svn -> git, потом svn останется в режиме read-only для истории.
А git, соответственно сначала только для чтения? Никаких преимуществ от его публикации тогда нет, ну вернее кто-нибудь может на нём собрать патчик и послать plain-text кому-нибудь, но профит не виден. Коммитить с его помощью в svn через git всё равно нельзя.
Z>Не знаю, народ хочет. sha1 в AssemblyVersion не засунешь, остальные задачи макрос решает, нумерует на основании тэга и количества комитов после него.
Народ не знает, чего хочет . tag.tag.yyyymmdd.hhmm я ещё отдалённо могу понять, хотя бы возрастание и уникальность почти гарантируется.
Для релизов, всегда можно сделать правильную версию.
Для личных билдов число коммитов ни о чём не говорит. Цель — разные AssemblyVersion для разных билдов на одной тачке?
Для автобилдов по репозиторию дата или номер билда отлично подходят.
Здравствуйте, IT, Вы писали:
IT>Четвёртая — придумать нормальное имя организации. NemerleTeam как-то совсем не в попад. Назвать хотя бы nemerle.
Какой-то киберсквотер уже занял https://github.com/nemerle/
IT>А лучше название nemerle оставить языку, а тому, что Влад называет платформой для создания компиляторов придумать название и назвать организацию таким именем.
Можно и так.
Осталось придумать название.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Иванков Дмитрий, Вы писали:
ИД>Два года назад, может и совпадение; он мало где упоминается, но вот тоже он http://sourceforge.net/users/nemerle.
Чувак из польши.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Иванков Дмитрий, Вы писали:
ИД>>>Публикация git-svn метаданных — плохая идея, оно пока что не работает. Z>>Я ничего специально не публиковал, склонировал и пушнул. ИД>Я про автоматически вставляемые git-svn-id в log messages, git-svn их читает при некоторых операциях.
Я понял. Не понял какие ко мне претензии, их вырезать надо было?
ИД>Ну, например полетел магический репозиторий, из которого был push, или просто надо запушить ещё svn-а в git. А может не выйти. ИД>Поэтому обновлять публичный git-svn клон в текущем состоянии git-svn — плохая идея.
Не понимаю, что значит обновлять. Подтягивать версии из svn? Почему вдруг?
Z>>Пока комиты идут только svn -> git, потом svn останется в режиме read-only для истории. ИД>А git, соответственно сначала только для чтения? Никаких преимуществ от его публикации тогда нет, ну вернее кто-нибудь может на нём собрать патчик и послать plain-text кому-нибудь, но профит не виден. Коммитить с его помощью в svn через git всё равно нельзя.
Чтож мне надо было купить закртый репо для теста
ИД>Народ не знает, чего хочет . tag.tag.yyyymmdd.hhmm я ещё отдалённо могу понять, хотя бы возрастание и уникальность почти гарантируется. ИД>Для релизов, всегда можно сделать правильную версию. ИД>Для личных билдов число коммитов ни о чём не говорит. Цель — разные AssemblyVersion для разных билдов на одной тачке? ИД>Для автобилдов по репозиторию дата или номер билда отлично подходят.
Все подходит, макрос тоже. Цель — нумеровать билды, билдсервера пока нет.
Здравствуйте, Иванков Дмитрий, Вы писали:
ИД>Я не очень понимаю этой хренотени, нафига собственно? О чём эта возрастающая цифра говорит? Чтобы различать билды между собой есть sha1 коммита, можно засосать туда же и тэги, красивые релизные номера ест-но делаются руками 2.1.1 или 2.1.1-sha1 (или как я сказал, неявно через тэги). Можно даже положить скрипт make_next_release, делающий тег 2.1.n+1 на текущем коммите.
Чтобы не было это "руками". "Руками" — это сразу в лес, так как это неминуемо приведет к граблям.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ziaw, Вы писали:
Z>Не знаю, народ хочет. sha1 в AssemblyVersion не засунешь, остальные задачи макрос решает, нумерует на основании тэга и количества комитов после него.
Где макрос? Покажи код.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Четвёртая — придумать нормальное имя организации. NemerleTeam как-то совсем не в попад. Назвать хотя бы nemerle. А лучше название nemerle оставить языку, а тому, что Влад называет платформой для создания компиляторов придумать название и назвать организацию таким именем.
Команде можно дать и отдельное название. Название RSDN мне лично нравится.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
ИД>>Поэтому обновлять публичный git-svn клон в текущем состоянии git-svn — плохая идея. Z>Не понимаю, что значит обновлять. Подтягивать версии из svn? Почему вдруг?
Потому что подтягивать их с другой тачки или другого локального git репа в тот же самый git-svn может не получится (два git svn clone в принципе могут иметь разные sha1).
И потому, что git workflow плохо совместим с (git-)svn в той части, когда надо закоммитить из git в svn что-то, что трогал кто-то ещё, кроме автора всех подтягиваний (ну, конечно отдавать ему на коммит изменения в виде патча или самому коммитить в svn напрямую — ok).
Z>Чтож мне надо было купить закртый репо для теста
Извини, видимо недопонимание. Для теста сколько угодно, я просто говорю, что долгосрочно по такой схеме иметь официальный git-svn репо — далеко не лучшая идея.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Ziaw, Вы писали:
Z>>Не знаю, народ хочет. sha1 в AssemblyVersion не засунешь, остальные задачи макрос решает, нумерует на основании тэга и количества комитов после него.
VD>Где макрос? Покажи код.
Здравствуйте, Иванков Дмитрий, Вы писали:
ИД>Извини, видимо недопонимание. Для теста сколько угодно, я просто говорю, что долгосрочно по такой схеме иметь официальный git-svn репо — далеко не лучшая идея.
Видимо да, недопонимание. Планы переехать туда совсем. Никаких официальных git-svn.
Если нам не помогут, то мы тоже никого не пощадим.
. tag.tag.yyyymmdd.hhmm я ещё отдалённо могу понять, хотя бы возрастание и уникальность почти гарантируется.
