ИД>>Публикация 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 для разных билдов на одной тачке?
Для автобилдов по репозиторию дата или номер билда отлично подходят.
Здравствуйте, Ziaw, Вы писали:
Z>Насколько я понял у нас стояло три проблемы мешающие переезду. Первая это svn externals. Вторая версии на основе номера svn ревизии. Третья подсветка кода.
А что с базой issues? В гуглкоде были удобные автоматические перекрестные ссылки между комитами и багами — это все накроется?
Насколько я понял у нас стояло три проблемы мешающие переезду. Первая это 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 на текущем коммите.
Здравствуйте, Иванков Дмитрий, Вы писали:
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 оставить языку, а тому, что Влад называет платформой для создания компиляторов придумать название и назвать организацию таким именем.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, 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.
Здравствуйте, IT, Вы писали:
IT>Такая организация уже есть. Но так мы ещё сильнее прибиваем гвоздями Nemerle к русскому комьюнити.
Не Nemerle, а его разработку. Оно по факту уже давно прибито. Потом не обязательно же расшифровывать название? Со временем это станет мемом. И никто не будет задумываться над его происхождением.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
IT>>Такая организация уже есть. Но так мы ещё сильнее прибиваем гвоздями Nemerle к русскому комьюнити. VD>Не Nemerle, а его разработку. Оно по факту уже давно прибито. Потом не обязательно же расшифровывать название? Со временем это станет мемом. И никто не будет задумываться над его происхождением.
Можно и так. Хватит нам на всё про всё .3GB? Или имеет смысл разориться на $25 в месяц на платный аккаунт?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Можно и так. Хватит нам на всё про всё .3GB? Или имеет смысл разориться на $25 в месяц на платный аккаунт?
1)Хватит.
2)Если когда-нибудь не хватит тогда и можно будет думать про разориться. Правда если проект разрастется до такого размера есть вероятность что они объем и бесплатно увеличат.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, seregaa, Вы писали:
S>А что с базой issues? В гуглкоде были удобные автоматические перекрестные ссылки между комитами и багами — это все накроется?
Проработал этот вопрос. Перенести их легко, только потеряется автор (как было сделано при переносе на гуглкод). Есть API для разных языков, есть даже готовые скриптики.
Со связями сложнее, надо запоминать соответствие номеров тикетов при переносе.
После этого нужно переделать гит репозитарий меняя в сообщениях ссылки на тикеты. Детали этого момента для меня пока не ясны, надо поспрошать экспертов по гиту, в теории это точно можно сделать, надо только понять легко ли автоматизировать.
После этого в проект с подготовленными тикетами и пустым репо надо пушнуть получившийся репозитарий, все тикеты автоматом свяжутся с ревизиями.
Здравствуйте, Ziaw, Вы писали:
Z>После этого нужно переделать гит репозитарий меняя в сообщениях ссылки на тикеты. Детали этого момента для меня пока не ясны, надо поспрошать экспертов по гиту, в теории это точно можно сделать, надо только понять легко ли автоматизировать.
Оказывается это очень просто делается. В эту команду надо передать скриптик который пофиксит комментарий к комиту. Только делать надо непосредственно в момент переезда, репозитарий будет новый, подцепить туда изменения из svn уже не получится.
стандартный git svn, как правило, предназначен для постоянной работы с удаленным svn репозиторием, поэтому он пишет много метаинформации в комитах, делает svn теги как git branch и т.д. что бы нормально работал двусторонняя связь svn <-> git
а svn2git как раз позволяет полностью перейти на git, нормально сделает тег и т.д.
Здравствуйте, Petrovich_Alex, Вы писали:
P_A>github предлагает 2 метода перейти с svn.
Это довольно небыстрая операция. Я бы не хотел ее повторять.
P_A>стандартный git svn, как правило, предназначен для постоянной работы с удаленным svn репозиторием, поэтому он пишет много метаинформации в комитах, делает svn теги как git branch и т.д. что бы нормально работал двусторонняя связь svn <-> git
Тэгов как бы немного. Их можно и руками, метаинформация карман не тянет, какие еще недостатки?
P_A>а svn2git как раз позволяет полностью перейти на git, нормально сделает тег и т.д.
P_A>>а svn2git как раз позволяет полностью перейти на git, нормально сделает тег и т.д.
Z>Насчет "и т.д." хотелось бы подробнее.
ну дык все описано
svn2git поддерживает список авторов, теги и бранчи приведет в вид гита, может обновляться из svn (через svn2git --rebase)...
в конечном итоге, мы слили 2 svn репозитория в один git и после этого наступило щасье...
история успеха:
Долгая разработка. Первый репозиторий (over 30000 commints) прошел несколько обновлений svn и в конечном итоге поломался, не дампился и не чинился, при получении истории отваливался, поэтому решили сделать новый svn репо и соответственно без истории . Когда новый достиг ~13000 коммитов, половину разработки перешли на git svn. Еще через ~5000 коммитов перенесли оба svn репозитория в 2 git репозитория (через svn2git), а потом слили 2 git в один. В итоге ничего не потеряли и получили всю историю правок проекта.
Здравствуйте, Ziaw, Вы писали:
IT>>Можно и так. Хватит нам на всё про всё .3GB? Или имеет смысл разориться на $25 в месяц на платный аккаунт? Z>Ты бы поговорил с авторами пигментов. Что им мешает закомитить мой лексер для немерла?
Где можно поговорить?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Четвёртая — придумать нормальное имя организации. NemerleTeam как-то совсем не в попад. Назвать хотя бы nemerle. А лучше название nemerle оставить языку, а тому, что Влад называет платформой для создания компиляторов придумать название и назвать организацию таким именем.
Здравствуйте, seregaa, Вы писали:
S>А что с базой issues? В гуглкоде были удобные автоматические перекрестные ссылки между комитами и багами — это все накроется?
Пишу тут скриптик для их миграции, возникла идея блоки кода показывать именно как блоки кода. Для этого надо их вычленить из issues и вставить перед каждой строкой 4 пробела. Есть у кого идеи/реализации сего действа? Можно конечно потом проапдейтить уже смигрированные, но хотелось бы сразу.
Раз пошла такая пьянка — режь последний огурец. Оказывается гитхаб поддерживает родной формат медиавики. Это означает, что перенести медиавики в гитхаб дело пары-тройки часов.
Что это нам дает? Во первых к редактированию вики будет нормальный интерфейс у всех участников. Во вторых можно редактировать вики через репозитарий, это глобальные поиск с заменой, это форки, можно поставить рубийный Gollum и править форкнутый вики локально.
Вики в качестве пачки файлов чрезвычайно удобная для рефакторинга вещь, а рефакторинг для вики ой как требуется. Ну и для переезда вики на новый сайт это будет в любом случае полезно.
Здравствуйте, seregaa, Вы писали:
S>А что с базой issues? В гуглкоде были удобные автоматические перекрестные ссылки между комитами и багами — это все накроется?
Основные отличия: есть всего два статуса — open и closed, все остальное достигается лейблами. С закрытием/связыванием тикетов по комиту тоже все нормально, нужно только сконвертить сообщения о комитах и заменить issuse $oldNumber на #$newNumber, комит с примером ссылок https://github.com/Ziaw/UssueMigrationTest/commits/master
Тикеты закрываются по времени комита, а не по времени пуша, это радует.
Здравствуйте, Ziaw, Вы писали:
IT>>Четвёртая — придумать нормальное имя организации. NemerleTeam как-то совсем не в попад. Назвать хотя бы nemerle. А лучше название nemerle оставить языку, а тому, что Влад называет платформой для создания компиляторов придумать название и назвать организацию таким именем.
Z>nemerle-org Z>nemerle-lang Z>nemerle-community
А без nemerle-?
Если нам не помогут, то мы тоже никого не пощадим.
Если добавлять проект в https://github.com/rsdn, то надо понимать, что, не знаю хорошо это или плохо, но не Nemerle будет ориентироваться на rsdn, а rsdn на Nemerle. Т.е. теперь весь RSDN целиком пишут Nemerle
NemerleTeam и мне не нравится. Я даже просил поляка переименоваться, но он видимо давно забыл о GitHub >__<
Здравствуйте, nCdy, Вы писали:
C>Если добавлять проект в https://github.com/rsdn, то надо понимать, что, не знаю хорошо это или плохо, но не Nemerle будет ориентироваться на rsdn, а rsdn на Nemerle. Т.е. теперь весь RSDN целиком пишут Nemerle
Не думаю что кто-то сильно поменяет ориентацию. А вот то, что Nemerle со временем может вылиться в большой проект вполне вероятно. В этом случае в нём может возникнуть не пара, а десятки репозиториев, например, как в mono. Тогда общая свалка с rsdn начнёт только мешаться.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, nCdy, Вы писали:
C>Удивительно, но в основной ветке Pygments нету и F#
При этом подсветка на гитхабе есть. Исключение? Вообще у меня чувство, что игнорируют они .net. При этом очень похожий язык (Nimrod) был добавлен всего 6 дней назад и смерджен сегодня.
Здравствуйте, Ziaw, Вы писали:
Z>При этом очень похожий язык (Nimrod) был добавлен всего 6 дней назад и смерджен сегодня.
Кривущий язычок.
До немерле ему как до луны.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
. tag.tag.yyyymmdd.hhmm я ещё отдалённо могу понять, хотя бы возрастание и уникальность почти гарантируется.
Если нам не помогут, то мы тоже никого не пощадим.
Со временем это станет мемом. И никто не будет задумываться над его происхождением.
. Когда новый достиг ~13000 коммитов, половину разработки перешли на git svn. Еще через ~5000 коммитов перенесли оба svn репозитория в 2 git репозитория (через svn2git), а потом слили 2 git в один. В итоге ничего не потеряли и получили всю историю правок проекта.
