Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 52
При миграции на Mercurial на данный момент не существует простого способа перенести svn:externals.
Вы пробовали subrepo? Если да, чем не подошел?
Он же эцсамое, пушит при пуше. А нада что бы тока пулил.
Изучали, но не стали пробовать. По нескольким причинам:
1) У нас было несколько собственных SVN репозиториев, связанных через externals (например, в репозиторий проекта A подгружаются файлы из репозитория проекта Common), и все их нужно было перенести на Меркуриал. Как в этом случае корректно перенести всю историю с внешними зависимостями я с трудом представляю
2) subrepo это все-таки не совсем svn:externals. Задача стояла сохранить историю всех репозиториев полностью работоспособной и идентичной оригиналу, и не было гарантии, что через suprepo это получится вообще. Способ описанный в статье достаточно простой и гарантированно дает нужный результат, поэтому не стали тратить время на эксперименты.
3) После некоторого времени активного использования svn:externals пришли к выводу, что внешние зависимости на уровне репозиториев не так уж и хороши, и тащить их в Меркуриал попросту не хотелось.
1) У нас было несколько собственных SVN репозиториев, связанных через externals (например, в репозиторий проекта A подгружаются файлы из репозитория проекта Common), и все их нужно было перенести на Меркуриал. Как в этом случае корректно перенести всю историю с внешними зависимостями я с трудом представляю
2) subrepo это все-таки не совсем svn:externals. Задача стояла сохранить историю всех репозиториев полностью работоспособной и идентичной оригиналу, и не было гарантии, что через suprepo это получится вообще. Способ описанный в статье достаточно простой и гарантированно дает нужный результат, поэтому не стали тратить время на эксперименты.
3) После некоторого времени активного использования svn:externals пришли к выводу, что внешние зависимости на уровне репозиториев не так уж и хороши, и тащить их в Меркуриал попросту не хотелось.
Мало что смыслю в SVN'ах, но лирическая часть очень понравилась.
/me прослезился…
Жалко Репозиторий :(
Статью не осилил, но автору плюс за трудолюбие :)
Хорошая художественная статья с качественными мыслями. И самое главное, что все закончилось хорошо.
P.S. Небольшая реклама моего товарища на правах совпадения тематики:
Если кого-то интересуется установка свежего Mercurial на IIS, то ознакомьтесь с топиком в песочнице:
habrahabr.ru/sandbox/21615/
P.S. Небольшая реклама моего товарища на правах совпадения тематики:
Если кого-то интересуется установка свежего Mercurial на IIS, то ознакомьтесь с топиком в песочнице:
habrahabr.ru/sandbox/21615/
Отличный стиль статьи!
PS: в данный момент тоже собираюсь переходить с СВН… Однако я думал переходить на гит.
Почему выбрали меркуриал? Какие у него очевидные преимущества относительно гита?
PS: в данный момент тоже собираюсь переходить с СВН… Однако я думал переходить на гит.
Почему выбрали меркуриал? Какие у него очевидные преимущества относительно гита?
У меркуриала лучше и понятнее интерфейс, хорошая справка — написано то что нужно и важно.
Если вас не смущает лазить в гуглу по каждому сложному вопросу на десять-двадцать минут вместо того, чтоб за 20 секунд прочитать во встроенном хелпе — можно и гит использовать. В принципе, ничего страшного в нем нет. Главное — не используйте bazaar :)
> 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 либо обходят стороной, либо стараются описать по минимуму. Видимо, сложилось неверное представление.
Хз, давно не читал статей про хг. По идее эта должна давать какое-то впечатление, но текста тут много:
stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/
stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/
Более взвешенно, спасибо.
И всё равно поведение по умолчанию с пушем всех бранчей по умолчанию не очень радует.
И всё равно поведение по умолчанию с пушем всех бранчей по умолчанию не очень радует.
> Я использую одновременно и гит, и меркуриал, поэтому не поддержу мнение, что между ними так уж сложно переходить :)
Ты пришëл уже на накатанную дорожку и тебе просто чëтко и ясно объяснили, что делать. А когда только начинают его использовать, всякая херня лезет очень здорово. :\
Ты пришëл уже на накатанную дорожку и тебе просто чëтко и ясно объяснили, что делать. А когда только начинают его использовать, всякая херня лезет очень здорово. :\
Про базар — можно в двух словах «почему»?
В двух словах? Можно — «это жопа».
Я на текущей работе вынужден пользоваться базаром (уже 2,5 месяца) и за последние две недели написал предложение о переходе на меркуриал, сделал презентацию и в принципе скоро должны проголосовать. :) У меня есть страничка на вики длиной в 2,5 тысячи слов, я постараюсь кратко основные моменты оттуда описать:
Первый пункт может казаться неважным, если до того не использовать hg или git. Но он важен, и для меня это основной камень преткновения.
Номера ревизий — это жопа. В базаре попытались сделать последовательные номера коммитов (как в свн — 1, 2, 3), которые бы сохранялись при клонировании, но они *не сохраняются*. В гите — только хеши ревизий, в хг — хеши и локальные номера, в базаре — только локальные номера. Хеши спрятаны глубоко и никто в компании, кроме меня, как до них добраться, никак не может запомнить. Это вообще дикая жопа выходит. Если ты знаешь номер чейнджсета, ты не можешь пойти к другому человеку и сказать «в чейнджсете ab32f трабла!» Ты должен отправить ему длинный хеш через джаббер, потому что базар не понимает сокращений. Не знаю, как выразить всю свою ненависть. :\
Коммиты других людей постоянно прячутся за мержами. Неприятно в большинстве случаев.
bzr send не умеет слать простые патчи по мылу, только бинарные и кошмарные. Неудобно, блин.
Ну, подсветку и паджинацию можно сделать через пайп, но это те мелочи, которые достают.
Мне пришлось написать пару экстеншенов для него для работы и должен сказать, что его внутренности — это пример одного из самых плохих исходных кодов, которые я видел в крупных опенсорсных питоновых проектах. Не, не пример одного, это самый плохой. Очень-очень плохо, двойка.
Могу немного попытаться продолжить на тему плюсов хг и гита, но мне кажется, что этого достаточно, да?
Я на текущей работе вынужден пользоваться базаром (уже 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 кажется логичным или не логичным в зависимости от задач, которые вы собираетесь на нём решать. Если логика не подходит под выбранный вами процесс разработки — надо просто взять другой инструмент, пока не поздно.
Либо подумать почему мне так неудобно и что я могу поменять в процессе. [/кэп]
[кэп]Построение dvcs кажется логичным или не логичным в зависимости от задач, которые вы собираетесь на нём решать. Если логика не подходит под выбранный вами процесс разработки — надо просто взять другой инструмент, пока не поздно.
Либо подумать почему мне так неудобно и что я могу поменять в процессе. [/кэп]
Но он серьëзно абсолютно нелогичен. Почему я забираю изменения из транка, делаю с ними мерж и в результате вижу «merge with trunk» вместо изменений из транка? А мой сосед потом забирает мои изменения, но видит этот «merge with trunk» вместо моих изменений. Не вижу, что именно здесь логично. :(
> Если логика не подходит под выбранный вами процесс разработки — надо просто взять другой инструмент, пока не поздно.
Тут возник клëвый прикол. У нас есть процесс, выстроенный под базар, с кучей репозиториев/бранчей, гейткипером и т.п. Если мы берëм хг или гит, то мы легко его можем поддерживать и даже двигаться в разные стороны. А с базаром двигаться некуда, у него один вариант, если не хочется давать доступ всем в главный репозиторий — куча отдельных репозиториев. :( У меня на диске текущие незамерженные бранчи проекта занимают 3 гига. Вроде немного, но это ж не видео, это текст.
Он очень ограничен в плане свободы передвижений. :(
> Если логика не подходит под выбранный вами процесс разработки — надо просто взять другой инструмент, пока не поздно.
Тут возник клëвый прикол. У нас есть процесс, выстроенный под базар, с кучей репозиториев/бранчей, гейткипером и т.п. Если мы берëм хг или гит, то мы легко его можем поддерживать и даже двигаться в разные стороны. А с базаром двигаться некуда, у него один вариант, если не хочется давать доступ всем в главный репозиторий — куча отдельных репозиториев. :( У меня на диске текущие незамерженные бранчи проекта занимают 3 гига. Вроде немного, но это ж не видео, это текст.
Он очень ограничен в плане свободы передвижений. :(
Видимо я чего-то не понимаю…
есть транк
что-то меняется в бранче
мерджится с транком, подтверждается.
опять меняется в бранче
мерджится с транком, подтверждается.
можно увидеть и что в транке и что было в мердже и что закоммитили… На каждом шагу видно кто что и когда сделал
По поводу прикола. Что-то не так в процессе, если есть огромные незамердженные бранчи. И они лежат на одной машине.
В чем невозможность движения? Организовать структуру бранчей, установить общие правила, _следить за четким их исполнением_. Всё просто работает. Двигаться в каком смысле?
Именно с базаром у нас работают до 10 человек, так что спорить не буду, конечно. Поэтому и интересен ваш опыт использования на больших проектах. А проект должен быть действительно большим, что бы исходники занимали гигабайты… Или вы вообще всё лепите в репозиторий?
есть транк
что-то меняется в бранче
мерджится с транком, подтверждается.
опять меняется в бранче
мерджится с транком, подтверждается.
можно увидеть и что в транке и что было в мердже и что закоммитили… На каждом шагу видно кто что и когда сделал
По поводу прикола. Что-то не так в процессе, если есть огромные незамердженные бранчи. И они лежат на одной машине.
В чем невозможность движения? Организовать структуру бранчей, установить общие правила, _следить за четким их исполнением_. Всё просто работает. Двигаться в каком смысле?
Именно с базаром у нас работают до 10 человек, так что спорить не буду, конечно. Поэтому и интересен ваш опыт использования на больших проектах. А проект должен быть действительно большим, что бы исходники занимали гигабайты… Или вы вообще всё лепите в репозиторий?
> можно увидеть и что в транке и что было в мердже и что закоммитили… На каждом шагу видно кто что и когда сделал
Я не пользуюсь гуем, к сожалению, привык к консоли или веб-интерфейсу (которого тоже нет, с логгерхедом немало возни), плюс под мак часто не собирают ничего.
> По поводу прикола. Что-то не так в процессе, если есть огромные незамердженные бранчи. И они лежат на одной машине.
Почему не так? У меня примерно 15 тикетов еще в стадии «не дошли до лайва», еще 5 — просто эксперименты, еще десяток я не удалил, в результате — 30 бранчей, каждый по 100 мегов (история длинная), 3 гига накопилось.
> В чем невозможность движения? Организовать структуру бранчей, установить общие правила, _следить за четким их исполнением_. Всё просто работает. Двигаться в каком смысле?
В том смысле, что я не могу три ветки в одном репозитории держать, например. Я не могу клонировать или не клонировать по желанию — мне нужно клонировать. Я не могу отправить патчик по мылу человеку, чтоб он его посмотрел и применил, если ему захочется, потому что для этого ему придëтся создавать новый клон, применять то, что выдал bzr send и смотреть — очень высокая цена за любое движение выходит. :(
> Именно с базаром у нас работают до 10 человек, так что спорить не буду, конечно.
У нас тоже всего 11 человек. А проект не слишком так, чтоб большой, там рабочая копия на 40 мб, из которых 30 — всякие картинки и оформление, остальное — код, темплейты и всякие мелочи.
Я не пользуюсь гуем, к сожалению, привык к консоли или веб-интерфейсу (которого тоже нет, с логгерхедом немало возни), плюс под мак часто не собирают ничего.
> По поводу прикола. Что-то не так в процессе, если есть огромные незамердженные бранчи. И они лежат на одной машине.
Почему не так? У меня примерно 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 — это вам поможет только в плане морального удовлетворения. Эмоционально это вам нравится, а это нет… Это только предположение — ни в коем случае не буду спорить. Почитаю вашу будущую статью — пока мало информации.
все можно посмотреть и без гуя, просто диффы и лог удобнее смотреть именно оттуда. Сомневаюсь, что под мак это не собирается ибо 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 часто не имеет отношения к тому, что произошло).
> Эмоционально это вам нравится, а это нет…
Эмоционально мне не нравится гит. Но я могу им пользоваться, это инструмент, а не его подобие.
Мне удобно смотреть историю и в хг, и в гите. И в сабвершене не испытывал проблем. Но базар прячет еë, и это раздражает. Это не шоу-стоппер.
> Вы патч мастер? Вам сливают всё, а вы мерджите? Не могу ничего посоветовать ибо не знаю вашего процесса. Просто выглядит подозрительно.
Не понимаю, что выглядит подозрительно? За последнюю неделю я завершил какое-то количество тикетов и они ждут, пока до них доберëтся гейткипер, а некоторые еще в процессе (потому что я переключался на саппорт/проблемы на лайве).
> :: Я не могу клонировать или не клонировать по желанию
> В смысле? готово — делаешь merge \ pull не готово — не делаешь. Что значит должен? В транк не должны попадать недоделки. Для этого есть бранчи фич. Клонировать (сделать branch) можно в любой момент и с любой ветки.
Если я хочу получить каждый тикет в отдельной ветке, в базаре меня заставляют делать новые клоны. Которые жрут время, занимают место и лежат в другом месте относительно предыдущего места работы. Что кроме всего еще значит то, что все мои tags-файлы уже невалидны, а у коллеги в эклипсе десятка три воркспейсов.
То, что в базаре репозиторий и ветка — это синонимы — это плохо. Очень плохо. Я могу иметь один репозиторий и много веток одновременно и в меркуриале, и в гите. Там DAG, почему мне инструмент не даëт с ним нормально работать?
> можно поставить, посмотреть и сделать bzr revert если не подходит, в чем проблема? Все, что не закоммичено — не закоммичено и места не занимает…
> bzr revert откатит до состояния последнего коммита.
Применение через bzr pull сделает коммит. Я могу сделать анкоммит, но я не могу посмотреть в мыле. А я хочу, потому что я привык и потому что это быстрее в несколько раз.
> Ерунда какая. А почему не положить их в библиотеку и держать в репозитории то, для чего он предназначен? Для исходников, вообщем-то.
Потому что репозиторий организовывал не я и потому что оформление меняется в процессе.
Я б сделал по отдельному репозиторию на каждый модуль и делал бы из них нормальные библиотеки, но я пока не могу такое продавить, никто не хочет.
> Потихоньку выясняется, что базар тут вообщем-то нипричем. А, как я и говорил, надо думать о процессах и организации работы.
Well, при чëм, конечно. Я написал список проблем, и 3 гига на диске — это не основная и не проблема.
Проблема в том, что он мешает мне общаться с коллегами, проблема в том, что у начала работы над тикетом стоимость выше той, которую я получу с меркуриалом или гитом, он неудобен (и не пытается таковым быть) — неужели расцветить всë или паджинировать так тяжело?
И я не могу его нормально расширять, чтоб улучшить воркфлоу. API базара плохое как внутреннее — питоновское, так и наружное — коммандлайновое (к примеру, return code часто не имеет отношения к тому, что произошло).
> Эмоционально это вам нравится, а это нет…
Эмоционально мне не нравится гит. Но я могу им пользоваться, это инструмент, а не его подобие.
> Не могу придумать зачем может понадобиться держать в одном репозитории три ветки.
При разработке программных продуктов — как минимум для разделения на текущую ветку для разработки плюс ветки для предыдущих мажорных версий для багфиксов. А разрабатываемых функций в данный момент тоже может быть несколько, намного удобнее делать это в отдельных ветках и потом сливать, чем в одной с перемешиванием истории. P.S. С базаром сталкиваться не приходилось, так что могу не очень точно понимать вашу дискуссию.
При разработке программных продуктов — как минимум для разделения на текущую ветку для разработки плюс ветки для предыдущих мажорных версий для багфиксов. А разрабатываемых функций в данный момент тоже может быть несколько, намного удобнее делать это в отдельных ветках и потом сливать, чем в одной с перемешиванием истории. P.S. С базаром сталкиваться не приходилось, так что могу не очень точно понимать вашу дискуссию.
:: намного удобнее делать это в отдельных ветках и потом сливать
Это и есть нормальное функционирование базара. Делаешь сколько угодно веток. По необходимости (читай готовности) сливаешь с основной. Вся история видна. Можно и локальные коммиты видеть (веток), если надо.
Пока дискуссии не было — просто обменялись опытом, я попытался понять о чем речь.
Это и есть нормальное функционирование базара. Делаешь сколько угодно веток. По необходимости (читай готовности) сливаешь с основной. Вся история видна. Можно и локальные коммиты видеть (веток), если надо.
Пока дискуссии не было — просто обменялись опытом, я попытался понять о чем речь.
Ах да, и whybzrisbetterthanx.github.com/
Mercurial на порядок дружественней для Windows пользователей. TortoiseGit все-таки еще достаточно сыроват.
Другим важным преимуществом для нас стало то, что Mercurial — основная VCS в FogBugz, это трекер, на который мы решили переехать.
Другим важным преимуществом для нас стало то, что Mercurial — основная VCS в FogBugz, это трекер, на который мы решили переехать.
спасибо за сайт!
это трындец, а не сайт
Возьмем, например, «staging area». Суть в то, что в git нужно по умолчанию указывать явно файлы, которые нужно закоммитить, а в hg — те, которые не нужно коммитить. Вот и вся разница. Из этого раздули кучу воды и изобрели специальный термин. При этом вопрос о том, какой подход лучше — уж точно очевидного ответа не имеет.
Но, вообще говоря, git и правда помощнее, чем hg (хотя и менее юзабельный, как минимум на первых порах).
Возьмем, например, «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 и правда помощнее, чем hg (хотя и менее юзабельный, как минимум на первых порах).
Да ну? Хотелось бы услышать, в каком месте?
> Да ну? Хотелось бы услышать, в каком месте?
Хорошо поймали. Не, конкретики от меня не будет тут) Писал про это только на уровне впечатлений: из коробки в git больше всего понапихано (stash тот же — attic и shelve показались неюзабельными и глючными, умудрился с ними пару изменений потерять), ну и подход «строго по ветке на фичу» в hg у меня как-то не уложился. Но hg в любом случае кажется гораздо удобнее.
Хорошо поймали. Не, конкретики от меня не будет тут) Писал про это только на уровне впечатлений: из коробки в git больше всего понапихано (stash тот же — attic и shelve показались неюзабельными и глючными, умудрился с ними пару изменений потерять), ну и подход «строго по ветке на фичу» в hg у меня как-то не уложился. Но hg в любом случае кажется гораздо удобнее.
Хз, для меня stash выглядит как недо-mq.
А строго по ветке на фичу я и в гите не применяю, и в хг — только для более-менее долгоиграющих изменений. Но это в своих проектах, на работе сейчас как раз воркфлоу строим и «по ветке на тикет» очень хорошо выходит. С букмарками.
Ну хг удобнее и проще, это да.
А строго по ветке на фичу я и в гите не применяю, и в хг — только для более-менее долгоиграющих изменений. Но это в своих проектах, на работе сейчас как раз воркфлоу строим и «по ветке на тикет» очень хорошо выходит. С букмарками.
Ну хг удобнее и проще, это да.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
История одного Репозитория