Комментарии 52
При миграции на Mercurial на данный момент не существует простого способа перенести svn:externals.

Вы пробовали subrepo? Если да, чем не подошел?
Он же эцсамое, пушит при пуше. А нада что бы тока пулил.
Изучали, но не стали пробовать. По нескольким причинам:
1) У нас было несколько собственных SVN репозиториев, связанных через externals (например, в репозиторий проекта A подгружаются файлы из репозитория проекта Common), и все их нужно было перенести на Меркуриал. Как в этом случае корректно перенести всю историю с внешними зависимостями я с трудом представляю
2) subrepo это все-таки не совсем svn:externals. Задача стояла сохранить историю всех репозиториев полностью работоспособной и идентичной оригиналу, и не было гарантии, что через suprepo это получится вообще. Способ описанный в статье достаточно простой и гарантированно дает нужный результат, поэтому не стали тратить время на эксперименты.
3) После некоторого времени активного использования svn:externals пришли к выводу, что внешние зависимости на уровне репозиториев не так уж и хороши, и тащить их в Меркуриал попросту не хотелось.
Мало что смыслю в SVN'ах, но лирическая часть очень понравилась.
Хорошая художественная статья с качественными мыслями. И самое главное, что все закончилось хорошо.

P.S. Небольшая реклама моего товарища на правах совпадения тематики:
Если кого-то интересуется установка свежего Mercurial на IIS, то ознакомьтесь с топиком в песочнице:
habrahabr.ru/sandbox/21615/
Отличный стиль статьи!
PS: в данный момент тоже собираюсь переходить с СВН… Однако я думал переходить на гит.
Почему выбрали меркуриал? Какие у него очевидные преимущества относительно гита?
У меркуриала лучше и понятнее интерфейс, хорошая справка — написано то что нужно и важно.

> hg help rebase | wc -l
63
> git help rebase | wc -l
670


Если вас не смущает лазить в гуглу по каждому сложному вопросу на десять-двадцать минут вместо того, чтоб за 20 секунд прочитать во встроенном хелпе — можно и гит использовать. В принципе, ничего страшного в нем нет. Главное — не используйте bazaar :)
Резюмируя сказанное в предыдущем десятке топиков про DVCS, отмечу что это в основном дело привычки. В Git и Mercurial несколько отличается философия веток и тегов, плюс наиболее часто используемые add/commit/push/pull/merge ведут себя по умолчанию по-разному, хотя по сути просто имеют разный набор ключей по-умолчанию. Потому пересесть с Git на Mercurial может быть также сложно, как и с VCS на DVCS :) Ну а со справкой помогают пара книжек, типа Git Book, достаточно один раз пролистать и потом в маны лазить только за специфичными ключами.
Спасибо за ответ! Просто еще не успел перенести репозитории на гит, поэтому пока колебался, и решил уточнить =)
Тогда уже окончательно остановлюсь на ГИТе. А с документацией проблем сильно не возникает, главное их читать =)
Я использую одновременно и гит, и меркуриал, поэтому не поддержу мнение, что между ними так уж сложно переходить :)

> Ну а со справкой помогают пара книжек

Ну да, пара книжек, гугл, маны… Пользоваться можно :)
В общем-то да, SVN вместе с Git используют же :) Просто нужно понимать, что не все DVCS одинаковые. Хотя мне Hg не понравился именно из-за веток: уж больно все пропагандируют сильно разветвлённые репозитории, а я стараюсь в основное хранилище передавать более-менее линейную историю. Быть может, это от чтения пропагандирующих статей.
Эээ… не уловил разницу хг и гита по отношению к веткам. В чëм идея?
В основном из-за того, что во всех статьях про Hg, которые я видел, основной упор делается на branch-per-repository, а named branches либо обходят стороной, либо стараются описать по минимуму. Видимо, сложилось неверное представление.
Ну, он предлагает вроде сделать alias nudge = 'push -r .'

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

Ты пришëл уже на накатанную дорожку и тебе просто чëтко и ясно объяснили, что делать. А когда только начинают его использовать, всякая херня лезет очень здорово. :\
В двух словах? Можно — «это жопа».

Я на текущей работе вынужден пользоваться базаром (уже 2,5 месяца) и за последние две недели написал предложение о переходе на меркуриал, сделал презентацию и в принципе скоро должны проголосовать. :) У меня есть страничка на вики длиной в 2,5 тысячи слов, я постараюсь кратко основные моменты оттуда описать:

  • no in-repo branches
  • absolutely useless revision numbers
  • mainline idea and merge-orientedness, log presentation sucks
  • no possibility to exchange with text/plain patches
  • no coloring, no auto-pagination of output
  • abolutely awful code and API


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

Номера ревизий — это жопа. В базаре попытались сделать последовательные номера коммитов (как в свн — 1, 2, 3), которые бы сохранялись при клонировании, но они *не сохраняются*. В гите — только хеши ревизий, в хг — хеши и локальные номера, в базаре — только локальные номера. Хеши спрятаны глубоко и никто в компании, кроме меня, как до них добраться, никак не может запомнить. Это вообще дикая жопа выходит. Если ты знаешь номер чейнджсета, ты не можешь пойти к другому человеку и сказать «в чейнджсете ab32f трабла!» Ты должен отправить ему длинный хеш через джаббер, потому что базар не понимает сокращений. Не знаю, как выразить всю свою ненависть. :\

Коммиты других людей постоянно прячутся за мержами. Неприятно в большинстве случаев.

bzr send не умеет слать простые патчи по мылу, только бинарные и кошмарные. Неудобно, блин.

Ну, подсветку и паджинацию можно сделать через пайп, но это те мелочи, которые достают.

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

Могу немного попытаться продолжить на тему плюсов хг и гита, но мне кажется, что этого достаточно, да?
Спасибо. Я сам пользуюсь базаром больше года и, в принципе очень доволен. Но я понимаю, что мои задачи слишком просты (мы не софтовая компания). Поэтому очень интересно было прочитать и продолжение. Но, конечно, но это не относится к топику, поэтому буду связываться с вами отдельно или ждать статьи на тему «реальное, практическое использование dvcs».

Еще раз спасибо.
Я подумываю написать в блог свежую статью на тему сравнения гита вс хг и плевка в сторону базара (ну, у меня к нему и раньше немного неприязненное отношение было, но за последние два месяца оно резко изменилось в сторону ненависти :)), за последний год как раз постоянно работал со всеми…
Когда мы выбирали dvcs был выбран именно базар как более логично построенный и более удобный для наших задач. Я с удовольствием прочитаю вашу статью и, возможно там мы немного поспорим \ обсудим. Считайте, что у вашей статьи будет как минимум один читатель, который её ждёт.

[кэп]Построение dvcs кажется логичным или не логичным в зависимости от задач, которые вы собираетесь на нём решать. Если логика не подходит под выбранный вами процесс разработки — надо просто взять другой инструмент, пока не поздно.

Либо подумать почему мне так неудобно и что я могу поменять в процессе. [/кэп]
Но он серьëзно абсолютно нелогичен. Почему я забираю изменения из транка, делаю с ними мерж и в результате вижу «merge with trunk» вместо изменений из транка? А мой сосед потом забирает мои изменения, но видит этот «merge with trunk» вместо моих изменений. Не вижу, что именно здесь логично. :(

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

Тут возник клëвый прикол. У нас есть процесс, выстроенный под базар, с кучей репозиториев/бранчей, гейткипером и т.п. Если мы берëм хг или гит, то мы легко его можем поддерживать и даже двигаться в разные стороны. А с базаром двигаться некуда, у него один вариант, если не хочется давать доступ всем в главный репозиторий — куча отдельных репозиториев. :( У меня на диске текущие незамерженные бранчи проекта занимают 3 гига. Вроде немного, но это ж не видео, это текст.

Он очень ограничен в плане свободы передвижений. :(
Видимо я чего-то не понимаю…


есть транк
что-то меняется в бранче
мерджится с транком, подтверждается.
опять меняется в бранче
мерджится с транком, подтверждается.

можно увидеть и что в транке и что было в мердже и что закоммитили… На каждом шагу видно кто что и когда сделал

По поводу прикола. Что-то не так в процессе, если есть огромные незамердженные бранчи. И они лежат на одной машине.

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

Именно с базаром у нас работают до 10 человек, так что спорить не буду, конечно. Поэтому и интересен ваш опыт использования на больших проектах. А проект должен быть действительно большим, что бы исходники занимали гигабайты… Или вы вообще всё лепите в репозиторий?
> можно увидеть и что в транке и что было в мердже и что закоммитили… На каждом шагу видно кто что и когда сделал

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

> По поводу прикола. Что-то не так в процессе, если есть огромные незамердженные бранчи. И они лежат на одной машине.

Почему не так? У меня примерно 15 тикетов еще в стадии «не дошли до лайва», еще 5 — просто эксперименты, еще десяток я не удалил, в результате — 30 бранчей, каждый по 100 мегов (история длинная), 3 гига накопилось.

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

В том смысле, что я не могу три ветки в одном репозитории держать, например. Я не могу клонировать или не клонировать по желанию — мне нужно клонировать. Я не могу отправить патчик по мылу человеку, чтоб он его посмотрел и применил, если ему захочется, потому что для этого ему придëтся создавать новый клон, применять то, что выдал bzr send и смотреть — очень высокая цена за любое движение выходит. :(

> Именно с базаром у нас работают до 10 человек, так что спорить не буду, конечно.

У нас тоже всего 11 человек. А проект не слишком так, чтоб большой, там рабочая копия на 40 мб, из которых 30 — всякие картинки и оформление, остальное — код, темплейты и всякие мелочи.
:: Я не пользуюсь гуем, к сожалению
все можно посмотреть и без гуя, просто диффы и лог удобнее смотреть именно оттуда. Сомневаюсь, что под мак это не собирается ибо qt, но спорить не буду. К тому же все можно посмотреть и из комманд лайна. Я делаю всё через комманд лайн, кроме очевидно неудобных вещей.

:: У меня примерно 15 тикетов еще в стадии «не дошли до лайва»
Вы патч мастер? Вам сливают всё, а вы мерджите? Не могу ничего посоветовать ибо не знаю вашего процесса. Просто выглядит подозрительно.

:: я не могу три ветки в одном репозитории держать
почему? держите их именно как ветки. Директория моэет быть та же. коммиты и все остальное отдельные.
А зачем хранить три ветки в одном репозиртории? Вы смените терминоголию и всё получится. Назовите репозиторием директорию и получите что вам недостает. Не могу придумать зачем может понадобиться держать в одном репозитории три ветки.

:: Я не могу клонировать или не клонировать по желанию
В смысле? готово — делаешь merge \ pull не готово — не делаешь. Что значит должен? В транк не должны попадать недоделки. Для этого есть бранчи фич. Клонировать (сделать branch) можно в любой момент и с любой ветки.

:: ему придëтся создавать новый клон, применять то, что выдал bzr send и смотреть — очень высокая цена за любое движение выходит. :(
можно поставить, посмотреть и сделать bzr revert если не подходит, в чем проблема? Все, что не закоммичено — не закоммичено и места не занимает…
bzr revert откатит до состояния последнего коммита.

А вообще это правильно «для экспериментов» создавать отдельные бранчи.

::40 мб, из которых 30 — всякие картинки и оформление
Ерунда какая. А почему не положить их в библиотеку и держать в репозитории то, для чего он предназначен? Для исходников, вообщем-то.

Просто перераспределив файлы вы получите репозитории менее 10 мб (думаю гораздо менее), которыми достаточно удобно и меняться и делать branch.

Потихоньку выясняется, что базар тут вообщем-то нипричем. А, как я и говорил, надо думать о процессах и организации работы. Я думаю, что если вы перейдёте на hg — это вам поможет только в плане морального удовлетворения. Эмоционально это вам нравится, а это нет… Это только предположение — ни в коем случае не буду спорить. Почитаю вашу будущую статью — пока мало информации.
> Я делаю всё через комманд лайн, кроме очевидно неудобных вещей.

Мне удобно смотреть историю и в хг, и в гите. И в сабвершене не испытывал проблем. Но базар прячет еë, и это раздражает. Это не шоу-стоппер.

> Вы патч мастер? Вам сливают всё, а вы мерджите? Не могу ничего посоветовать ибо не знаю вашего процесса. Просто выглядит подозрительно.

Не понимаю, что выглядит подозрительно? За последнюю неделю я завершил какое-то количество тикетов и они ждут, пока до них доберëтся гейткипер, а некоторые еще в процессе (потому что я переключался на саппорт/проблемы на лайве).

> :: Я не могу клонировать или не клонировать по желанию
> В смысле? готово — делаешь merge \ pull не готово — не делаешь. Что значит должен? В транк не должны попадать недоделки. Для этого есть бранчи фич. Клонировать (сделать branch) можно в любой момент и с любой ветки.

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

То, что в базаре репозиторий и ветка — это синонимы — это плохо. Очень плохо. Я могу иметь один репозиторий и много веток одновременно и в меркуриале, и в гите. Там DAG, почему мне инструмент не даëт с ним нормально работать?

> можно поставить, посмотреть и сделать bzr revert если не подходит, в чем проблема? Все, что не закоммичено — не закоммичено и места не занимает…
> bzr revert откатит до состояния последнего коммита.

Применение через bzr pull сделает коммит. Я могу сделать анкоммит, но я не могу посмотреть в мыле. А я хочу, потому что я привык и потому что это быстрее в несколько раз.

> Ерунда какая. А почему не положить их в библиотеку и держать в репозитории то, для чего он предназначен? Для исходников, вообщем-то.

Потому что репозиторий организовывал не я и потому что оформление меняется в процессе.

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

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

Well, при чëм, конечно. Я написал список проблем, и 3 гига на диске — это не основная и не проблема.

Проблема в том, что он мешает мне общаться с коллегами, проблема в том, что у начала работы над тикетом стоимость выше той, которую я получу с меркуриалом или гитом, он неудобен (и не пытается таковым быть) — неужели расцветить всë или паджинировать так тяжело?

И я не могу его нормально расширять, чтоб улучшить воркфлоу. API базара плохое как внутреннее — питоновское, так и наружное — коммандлайновое (к примеру, return code часто не имеет отношения к тому, что произошло).

> Эмоционально это вам нравится, а это нет…

Эмоционально мне не нравится гит. Но я могу им пользоваться, это инструмент, а не его подобие.
> Не могу придумать зачем может понадобиться держать в одном репозитории три ветки.
При разработке программных продуктов — как минимум для разделения на текущую ветку для разработки плюс ветки для предыдущих мажорных версий для багфиксов. А разрабатываемых функций в данный момент тоже может быть несколько, намного удобнее делать это в отдельных ветках и потом сливать, чем в одной с перемешиванием истории. P.S. С базаром сталкиваться не приходилось, так что могу не очень точно понимать вашу дискуссию.
:: намного удобнее делать это в отдельных ветках и потом сливать
Это и есть нормальное функционирование базара. Делаешь сколько угодно веток. По необходимости (читай готовности) сливаешь с основной. Вся история видна. Можно и локальные коммиты видеть (веток), если надо.

Пока дискуссии не было — просто обменялись опытом, я попытался понять о чем речь.
Да, но для этого нужно делать соответствующее количество папок. Имхо, именно это большинство считает минусом.
Mercurial на порядок дружественней для Windows пользователей. TortoiseGit все-таки еще достаточно сыроват.
Другим важным преимуществом для нас стало то, что Mercurial — основная VCS в FogBugz, это трекер, на который мы решили переехать.
это трындец, а не сайт

Возьмем, например, «staging area». Суть в то, что в git нужно по умолчанию указывать явно файлы, которые нужно закоммитить, а в hg — те, которые не нужно коммитить. Вот и вся разница. Из этого раздули кучу воды и изобрели специальный термин. При этом вопрос о том, какой подход лучше — уж точно очевидного ответа не имеет.

Но, вообще говоря, git и правда помощнее, чем hg (хотя и менее юзабельный, как минимум на первых порах).
если чесно, я hg никогда не пользовался. есть в меркуриале аналог git add -p? Это добавления изменений в staging area по чанкам, а не весь файл полностью.
да, hg record — и дальше интерактивная консольная штуковина вылезает, которая спрашивает, что добавлять, а что нет
хм. интерактивная консоль это немножко другое. но спасибо, хорошо что есть такая возможность.
да вроде то же самое абсолютно, только что git add -p попробовал: для каждого куска кода в консоли спрашивается, что с ним делать, можно целиком с файлом какие-то операции сделать, или до конца все оставшиеся изменения добавить/игнорировать
хотя разница есть — git add -p не коммитит, а hg record — это интерактивная замена hg commit
Еще есть crecord, это record с интерфейсом на curses, и можно отдельные линии выбирать.
Еще не надо забывать, что cheap local branching — тоже псевдопреимущество над hg. Всë то, что они описывают, есть в hg.

> Но, вообще говоря, git и правда помощнее, чем hg (хотя и менее юзабельный, как минимум на первых порах).

Да ну? Хотелось бы услышать, в каком месте?
> Да ну? Хотелось бы услышать, в каком месте?

Хорошо поймали. Не, конкретики от меня не будет тут) Писал про это только на уровне впечатлений: из коробки в git больше всего понапихано (stash тот же — attic и shelve показались неюзабельными и глючными, умудрился с ними пару изменений потерять), ну и подход «строго по ветке на фичу» в hg у меня как-то не уложился. Но hg в любом случае кажется гораздо удобнее.
Хз, для меня stash выглядит как недо-mq.

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

Ну хг удобнее и проще, это да.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.