стабильное решение для Hg/Git <-> Subversion

у меня уже 2 года используется git-svn - полет нормальный. коммитов порядка 100 тыс за текущую историю, пачка веток в svn и т.д.

> у меня уже 2 года используется git-svn - полет нормальный

Если с использованием Git 2 человека делают по нескольку коммитов, а потом отсылают их в SVN - что происходит?

что с фичами? история, rename, integrate - всё ок? что с проклятыми svn-externals?

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

а если не склеивать? ;)

у гита нет аналога svn-externals. есть костыли в виде скриптовых хуков, но это не торт. в гите такие вещи нужно подключать как субмодуль.

то есть автоматом externals в субмодули не переколбасится с помощью git-svn?

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

когда делаешь локальный гит из свн-а, в котором есть svn-externals, тебе локально не подтягивается содержимое этих экстерналов, так что и модифицировать их не сможешь :).

зависит от того, как сделаны коммиты - у меня обычно уходит пачкой по коммиту в svn для каждого из гитовских

rename/history - все нормально. externals вроде нет

> зависит от того, как сделаны коммиты - у меня обычно уходит пачкой по коммиту в svn для каждого из гитовских

И что будет, если в таком стиле работают одновременно 2 человека (или более)?

> rename/history - все нормально.

Не совсем нормально - mergeinfo не обновляется, а без него svn про переименования ничего не знает. Впрочем mergeinfo и так костыль, так что не страшно.

> И что будет, если в таком стиле работают одновременно 2 человека (или более)?

Ничего необычного. За исключением того, что из-за отсутствия mergeinfo svn blame будет показывать неправильного автора для мержей и переименований, сделанных через гит.

> Впрочем mergeinfo и так костыль, так что не страшно.

Ну то есть в Git не будет информации о merge'ах, выполненных в SVN, а SVN, соответственно, не будет знать о merge'ах, выполненных в Git?

И что будет, если в таком стиле работают одновременно 2 человека (или более)?

Ничего необычного.

2 человека начали работу в Git с SVN-ревизии trunk@100, сделали по нескольку коммитов, каждый коммит должен стать ревизией SVN. Кто-то отправляет изменения в SVN первым; когда второй отправляет в SVN свои изменения, _что_ будет? Я не спрашиваю, будет ли это «обычно».

«обычно» это конфликт в случае исправления общих строк, и merge в случае, если все изменения объединяются?

> «обычно» это

Я не спрашиваю о том, что такое «обычно». И про «необычно» тоже не спрашиваю.

git-svn та еще шляпа. Заместо я вёл собственный git репозиторий с самописными скриптами прямо в svn working copy, которые постоянно подгружали коммиты (svn co, git commit -am 'svn sync'), а мои наработки отправлялись обратно в виде одного большого патча, опять таки скриптом.

Но даже такое извращение того стоило: бранчи, stash, неожиданные быстрофиксы, все блага цивилизации.

> Но даже такое извращение того стоило: бранчи

Следов которых в SVN просто нет («мои наработки отправлялись обратно в виде одного большого патча»)?

В моем случае было просто: никому не нужны были следы. Начальство интересовал код, закрывающий таски в трекере, только и всего. А разработчикам нужна возможность взять транк и изредка svn blame.

Поэтому локальный git репозиторий, в котором я вел разработку, никого не напрягал.

ну чтобы ответить тебе, есть ли «необычные» вещи, стоит понять, что значит твоё определение слова «обычно».

> ну чтобы ответить тебе, есть ли «необычные» вещи

Еще раз, медленно и печально: я спрашиваю, _что_ происходит в описанной мной ситуации. О том, является ли происходящее «обычным» или «необычным», я не спрашиваю.

По-моему, тебя тут тонко троллят. )))

> По-моему, тебя тут тонко троллят. )))

Неизбежный риск %)

>При этом очень бы НЕ хотелось бы загадить основной репозиторий странными коммитами, коммитами без комментов

У нас это в SVN регулярно происходит безо всяких DVCS) Гит хотя бы запрещает коммитить без комментария

>Поэтому локальный git репозиторий, в котором я вел разработку, никого не напрягал.

Можно юзать гит-зеркало, а потом коммитить патчи в SVN. На сервере, соответственно, git-svn, в котором пост-коммит-хук SVN запускает фетч

присоединяюсь к вопросу)

А чо, Mercurial никто не пользуется шоле?

> А чо, Mercurial никто не пользуется шоле?

В роли фронтенда к SVN - видимо, никто.

>Следов которых в SVN просто нет («мои наработки отправлялись обратно в виде одного большого патча»)?

в гите несколько иная культура в подходе коммитов, мерджей и тд. где-то недавно в каком-то топике отписывал названия пары книжек по гиту. попробуй почитай. уверяю, волосы в разных местах зашевелятся от возможностей гита ;). свн после него тебе покажется каменным веком :).

вот эту для начала http://rockablepress.com/books/getting-good-with-git/ (она коротенькая)

а вот эту для качественного погружения http://progit.org/book/

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

Ыыыы... вы, гитеры, классные парни, но дислектики в большинстве. Я знаю о DVCS всё, что нужно знать на практике, и задаю конкретнный впрос о git-svn.

> но дислектики в большинстве.

Или, альтернативно, тролли :)

>Или, альтернативно, тролли :)

нормально... ему тут пытаются ответить на вопросы, а в ответ тролем окрестили :). более того, здесь нет апологетов гита или свн.

Я знаю о DVCS всё, что нужно знать на практике, и задаю конкретнный впрос о git-svn.

мне кажется ты пытаешься узреть всеобъемлющий тулкит, производящий полноценный воркфлоу между двумя системами контроля версий. прежде всего стоит понять, что этот инструмент сделан для простоты миграции с свн на гит и уж ни в коем разе не организовывать полноценный командный девелопмент. Разумеется, есть множество вариаций, когда этот «мостик» попросту не сможет протащить через себя какие-то витьеватости твоих долгих потуг в каком-то куске кода.

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

>> Или, альтернативно, тролли :)

нормально... ему тут пытаются ответить на вопросы, а в ответ тролем окрестили :)

Как то старнно мне отвечают на вопрос http://www.linux.org.ru/jump-message.jsp?msgid=5760213&cid=5762459

мне кажется ты пытаешься узреть всеобъемлющий тулкит, производящий полноценный воркфлоу между двумя системами контроля версий

Мне просто интересно, научилась ли хоть какая-нибудь прослойка между DVCS и SVN нормально отображать граф версий, в котором есть две или более веток.

зыж лично у меня нет желания тебе что-то доказать. свн хорош тем, что он прост как валенок

Если что, я ушел с SVN 5+ лет назад, и мне не нужно объяснять, что такое DVCS и как ими пользоваться.