| 1.1, Xasd (ok), 14:36, 03/11/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
 молодцы! осталось исправить недароботку с хранением-и-использованием файловых имён (кодировкой)
вобщем проект развиватся, рад за него! :-)
# p.s.: сам пользуюсь Git
| | |
| 1.2, добрый дядя (?), 14:52, 03/11/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
ура! Mercurial реально самая лучшая мощная и простая DVCS, а в git приходится долго ломать голову, нет уверенности в инструменте
а с Mercurial всегда уверен что все работает как надо и ты сможешь разобраться как пользоваться самыми сложными ее возможностями - факт, в git не так
минус - кодировка имен... были проблемы, подтверждаю
кто знает - как там дела обстоят - почему проблемы?
неужели там не UTF-8?
| | |
| |
| 2.3, Andrey Mitrofanov (?), 15:03, 03/11/2011 [^] [^^] [^^^] [ответить]
| –1 +/– |
>а в git приходится долго ломать
> а с Mercurial всегда уверен что все
Зачитайте полный список автотренинговых мантр, пожалуйста? Ну, мож в мане иль на сайте уже есть?? А ликёро-водочный сегодня нарядов не прислал?...
| | |
| 2.4, Дровосеков Игнат (?), 15:06, 03/11/2011 [^] [^^] [^^^] [ответить]
| +6 +/– |
Спорно что mercurial лучше git, git более прозрачный и понятный. Да и в mercurial очень неудобные бранчи, я бы даже сказал отвратительные.
| | |
| |
| 3.5, Аноним (-), 15:10, 03/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
Бранчи в mercurial такие же, как и в git. Более того, в mercurial есть 3 способа ветвления, а в git - только 2.
| | |
| |
| 4.13, Дровосеков Игнат (?), 15:36, 03/11/2011 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> Бранчи в mercurial такие же, как и в git. Более того, в mercurial есть 3 способа ветвления, а в git - только 2.
И не один способ ветвления в mercurial не может сравниться по удобству и простате с бранчами из git. Работаю и с mercurial и с git. В git с ветвлениями проще получается.
| | |
|
| 3.7, B7W (?), 15:17, 03/11/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Он не лучше, и не хуже. Он легче. Для людей кто впервые встречается с VCS, mecrurail это то что нужно. Ты не выстрелишь себе в ногу. Плюс в нем есть GUI и встроенный приличный web server и много еще другого. Одни замуты с users/ssh в git чего стоят.
| | |
| |
| 4.9, Аноним (-), 15:21, 03/11/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> Одни замуты с users/ssh в git чего стоят.
Зато в git можно синкать хоть разные диры между собой, хоть патч на флешке принести. Порой реально удобно. А в hg - ну знаете, админить еще один самобытный вебсервант не очень то и хотелось.
| | |
| |
| |
| 6.27, Аноним (-), 20:11, 03/11/2011 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> что подразумевается под разными дирами?
Вася работает в /home/vasya а петя - в /home/petya, допустим на 1 машине. Можно взять да засинхрить их. Для гита это совершенно нормально.
| | |
|
| 5.20, добрый дядя (?), 16:28, 03/11/2011 [^] [^^] [^^^] [ответить]
| +7 +/– | |
> Зато в git можно синкать хоть разные диры между собой, хоть патч на флешке принести. Порой реально удобно. А в hg - ну знаете, админить еще один самобытный вебсервант не очень то и хотелось.
с добрым утром, в Mercurial тоже это можно делать, причем из TortoiseHG в GUI на любой ОС тыкай себе с чем синхронизоваться, хоть с флэшкой, а hg bundle в GUI и hg unbundle это еще лучше чем патчи, это равносильно hg pull/push, только на лошадях
веб сервер может быть как свой, как встроенный, так и любой, причем опять же из GUI one-click сервер и вот с тебя уже твой сосед качает
Mercurial очень простая и мощная DVCS, любые нападки с "git лучше он тото это" - просто из за неосведомленности
| | |
|
| 4.14, Дровосеков Игнат (?), 15:45, 03/11/2011 [^] [^^] [^^^] [ответить]
| –11 +/– | |
> Он не лучше, и не хуже. Он легче. Для людей кто впервые встречается с VCS, mecrurail это то что нужно. Ты не выстрелишь себе в ногу. Плюс в нем есть GUI и встроенный приличный web server и много еще другого. Одни замуты с users/ssh в git чего стоят.
Для новичка, незнакомого с контролем версий git проще, благо есть куча полезных ресурсов по нему. С mercurial все так же но ресурсов меньше.
Выстрелить в ногу можно и с git и с mercurial. При чем с mercurial получается больнее.
Встроенный web server сомнительный плюс, так как новичкам он не нужен, только отвлекать будет. Хотя возможно кому-то полезно.
| | |
| |
| 5.22, добрый дядя (?), 16:31, 03/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Встроенный web server сомнительный плюс, так как новичкам он не нужен, только
> отвлекать будет. Хотя возможно кому-то полезно.
кому-то??? ты можешь работать без центрального сервера без проблем и из GUI, один клик и с тебя качает сосед, причем он же в GUI, ничего не перелопачивая
GUI к Mercurial это отдельный момент, выше всяческих похвал
а один только GUI убивает удобства git-а, и то едва ли они есть
я пользовался долго и git и Mercurial - hg явно лучше, подтверждено на практике как своей так и многих других
| | |
| |
| 6.38, Дровосеков Игнат (?), 12:14, 04/11/2011 [^] [^^] [^^^] [ответить]
| +/– | |
Новичку не в коем случае нельзя знакомиться с системой контроля версий с GUI. Начинать всегда нужно с командной строки.
> GUI к Mercurial это отдельный момент, выше всяческих похвал
а один только GUI убивает удобства git-а, и то едва ли они есть
Я вот не пользуюсь GUI не к одной системе контроля версий. Для программиста это неудобно и медленно.
> я пользовался долго и git и Mercurial - hg явно лучше, подтверждено на практике как своей так и многих других
А я пользовался мозгом и мне не важно что использовать, хоть git, хоть mercurial, хоть svn. Для главное достоинство git удобные бранчи, при работе над проектом нескольких программистов, необходимость в бранчах встает очень остро. А mercurial в этом плане не намного лучше svn. В mercurial просто другой подход к бранчеванию, не такой удобный как в git, но вполне оправданный и имеющий право на жизнь. Возможно вы просто имеете дело с разработкой такого ПО для которого mercurial хватает, у меня доже большую часть времени mercurial не вызывает нареканий, кроме тех редких случаев когда необходимо поддерживать сразу до 3 бранчей с постоянными между между ними.
| | |
| |
| 7.41, PereresusNeVlezaetBuggy (ok), 13:08, 04/11/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
 >[оверквотинг удален]
> А я пользовался мозгом и мне не важно что использовать, хоть git,
> хоть mercurial, хоть svn. Для главное достоинство git удобные бранчи, при
> работе над проектом нескольких программистов, необходимость в бранчах встает очень остро.
> А mercurial в этом плане не намного лучше svn. В mercurial
> просто другой подход к бранчеванию, не такой удобный как в git,
> но вполне оправданный и имеющий право на жизнь. Возможно вы просто
> имеете дело с разработкой такого ПО для которого mercurial хватает, у
> меня доже большую часть времени mercurial не вызывает нареканий, кроме тех
> редких случаев когда необходимо поддерживать сразу до 3 бранчей с постоянными
> между между ними.
Скажем так, в Mercurial есть как минимум mq, который представляет альтернативу как лёгким ветка Git'a, так и его stash; не прямой аналог, но конечный результат аналогичен. А там уж кому что удобнее использовать, конечно. :)
| | |
|
|
| 5.37, Michael Shigorin (ok), 02:18, 04/11/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Выстрелить в ногу можно и с git и с mercurial.
Значит, всё в порядке -- вот и давайте порадуемся лучше, что выбор есть :)
Пользователям и разработчикам hg -- поздравления с релизом, и чтоб инструмент побольше помогал да поменьше на себя внимания требовал :)
| | |
|
|
| 3.8, Аноним (-), 15:19, 03/11/2011 [^] [^^] [^^^] [ответить]
| –3 +/– |
Еще гит реально быстрый. В отличие от. Эффективно передает изменения по сети, но можно и хоть на флоппике патч принести. Как по мне - он симпатичнее этой странной кривоватой и тормознутой hg.
| | |
| |
| |
| 5.29, Аноним (-), 20:30, 03/11/2011 [^] [^^] [^^^] [ответить] | –1 +/– | Ага, вот так Для начала там нас встречает эпичная фраза ------------- --... большой текст свёрнут, показать | | |
| |
| 6.36, Maddy (?), 00:05, 04/11/2011 [^] [^^] [^^^] [ответить]
| +2 +/– |
Блин ... цитируя Филатова - "Зарядила как удод- что не слово то Федот!" - это про соседние диры
hg pull --update ../hg/other_dir/ чем не угодил ? или через ssh ? или hg bundle и опять-таки pull ? или hg serve и hg pull ...
Резюме - Чукча хэлп не читал и в руках не держал ....
| | |
| |
| 7.58, Аноним (-), 15:37, 09/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Блин ... цитируя Филатова - "Зарядила как удод- что не слово то
> Федот!" - это про соседние диры
А, то-есть возражений по поводу того что при _практическом_ использовании с дефолтными настройками хг в отличие от гита тормоз вы не имеете?
> Резюме - Чукча хэлп не читал и в руках не держал ....
Посмотрев на то как оно в разы сливает гиту на типовых операциях с репами исходников, а не какими-то больными на голову бэкэндами для вебни - я разумеется напер на изучение гита, а не этой странной хрени.
| | |
|
|
|
|
| 3.12, B7W (?), 15:30, 03/11/2011 [^] [^^] [^^^] [ответить]
| +2 +/– | |
Да git быстрее/навороченей, но готов поспорить что 70% из этого никогда не трогается.
Зачем их сравнивать? это две хорошие утилиты, и славо богу что есть какая то конкуренция и выбор.
| | |
| |
| 4.15, Дровосеков Игнат (?), 15:48, 03/11/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> Да git быстрее/навороченей, но готов поспорить что 70% из этого никогда не трогается.
Еще как трогается.
| | |
| 4.31, Аноним (-), 20:40, 03/11/2011 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Да git быстрее/навороченей, но готов поспорить что 70% из этого никогда не трогается.
А 95% населения вообще идиоты и им вообще никакие гиты и меркуриалы не сдались :)
| | |
|
|
| 2.10, Аноним (-), 15:22, 03/11/2011 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> приходится долго ломать голову, нет уверенности в инструменте
Судя по количеству пользователей git и бурному росту гитхаба - дело все-таки не в бобине, а в том кто в кабине.
| | |
| |
| 3.11, develop7 (ok), 15:28, 03/11/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
 >> приходится долго ломать голову, нет уверенности в инструменте
> Судя по количеству пользователей git и бурному росту гитхаба - дело все-таки не в бобине, а в том кто в кабине.
«миллион мух не может ошибаться»©
если бы не github, это поделие в жизни бы не вылезло за пределы LKML.
| | |
| |
| 4.16, Дровосеков Игнат (?), 15:53, 03/11/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> если бы не github, это поделие в жизни бы не вылезло за пределы LKML.
bitbucket не смог сделать mercurial популярным. Так что дело в git, а не в github.
| | |
| |
| 5.25, develop7 (ok), 17:12, 03/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
>> если бы не github, это поделие в жизни бы не вылезло за пределы LKML.
> bitbucket не смог сделать mercurial популярным. Так что дело в git, а не в github.
не было pull request, вот и не смог. так что дело в github
| | |
| |
| 6.39, Дровосеков Игнат (?), 12:21, 04/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
>>> если бы не github, это поделие в жизни бы не вылезло за пределы LKML.
>> bitbucket не смог сделать mercurial популярным. Так что дело в git, а не в github.
> не было pull request, вот и не смог. так что дело в
> github
А еще у них раньше был интерфейс не красивый и цвета сайты были не подходящими к фазе луны.
Истинным популяризатором git был Линус. Так что если уж кого и винить в популярности git, то его, а не github.
| | |
| |
| 7.43, develop7 (ok), 14:43, 04/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
>>>> если бы не github, это поделие в жизни бы не вылезло за пределы LKML.
>>> bitbucket не смог сделать mercurial популярным. Так что дело в git, а не в github.
>> не было pull request, вот и не смог. так что дело в github
> А еще у них раньше был интерфейс не красивый и цвета сайты были не подходящими к фазе луны.
Неа. Киллерфичей github являлась возможность одной кнопкой вмергать pull request. У bitbucket этого не было, т.к. они полагались на hg pull + hg merge + hg push. 3 действия против одного. Продолжать?
| | |
|
|
|
| 4.32, Аноним (-), 20:41, 03/11/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
> «миллион мух не может ошибаться»©
> если бы не github, это поделие в жизни бы не вылезло за пределы LKML.
Наверное именно поэтому я сначала на gitorious наткнулся :). Кстати они еще и сырец своего вебгуя скачать дают, если вдруг это надо.
| | |
| |
| 5.33, PereresusNeVlezaetBuggy (ok), 20:46, 03/11/2011 [^] [^^] [^^^] [ответить]
| +3 +/– |
>> «миллион мух не может ошибаться»©
>> если бы не github, это поделие в жизни бы не вылезло за пределы LKML.
> Наверное именно поэтому я сначала на gitorious наткнулся :). Кстати они еще
> и сырец своего вебгуя скачать дают, если вдруг это надо.
Ребят, вы чего? За Git'ом стояло имя Линуса. Этого было более чем достаточно для его популярности, по крайней мере на первых порах. А поскольку он оказался местами весьма толковым, то и успех не заставил себя ждать. А вот если бы его презентовал дядя Петя из Магадана, то шансов пробиться у него было бы меньше.
Я лично всё же почему-то больше люблю Mercurial. :) Но Git'ом тоже иногда пользуюсь, и могу сказать, что для типовых задач они вполне взаимозаменяемы. Можно с тем же успехом спорить Mercedes vs. BMW...
| | |
|
|
|
|
| 1.6, Аноним (-), 15:17, 03/11/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
> Быстродействие:
> Высокая производительность работы с хранилищем, не зависящая от числа
> элементом в нем (O(1) revlog);
Cool story, bro! Но гит почему-то гораздо приятнее в использовании в этом плане.
| | |
| 1.17, V (??), 16:04, 03/11/2011 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
hg примерно в двести раз интуитивно понятнее, чем git, и примерно в четыреста раз гибче в настройке как серверной так и клиентской части.
и, да, у git в рф кроме "Дровосеков Игнат" из пользователей есть кто-то? ))
| | |
| |
| 2.23, добрый дядя (?), 16:33, 03/11/2011 [^] [^^] [^^^] [ответить]
| –5 +/– |
> hg примерно в двести раз интуитивно понятнее, чем git, и примерно в
> четыреста раз гибче в настройке как серверной так и клиентской части.
ФАКТ! подпишусь под каждым словом
| | |
| 2.40, Kodirr (?), 12:30, 04/11/2011 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> hg примерно в двести раз интуитивно понятнее, чем git,
Я вообще полный чайник во всех DVCS, но нужно было как-то освоить - вдруг пригодится! Начал с git, общую концепцию понял, но всё остальное показалось каким-то мракобесием. Потом решил посмотреть на Mercurial - на удивление, стало понятно сразу всё! С ним и остался.
| | |
|
| 1.42, ruslan (??), 13:19, 04/11/2011 [ответить] [﹢﹢﹢] [ · · · ] | +1 +/– |  Мои поздравления разработчикам Mercurial Поскольку тут идет очередной холивар M... большой текст свёрнут, показать | | |
| |
| 2.44, добрый дядя (?), 16:45, 04/11/2011 [^] [^^] [^^^] [ответить]
| +3 +/– |
большое спасибо за интересный дельный комментарий, из которого можно узнать интересные факты:
- поддержка нормальных локальных веток
- Squash Merge
- система хранения репозитория
про локальные ветки не задумывался никогда, squash merge полезная штука, система хранения это да, несколько не оптимальна для вышеописанного случая
кажется знаю что такое локальные ветки, это те что не будут отправляться на сервер с push, важная вещь, и squash merge тоже крайне полезен был бы, уверен что по мере развития в Mercurial в нем появятся и такие возможности
а так да: поддержка любых ОС, удобнейший GUI на PyQt, числовая нумерация коммитов - с ними удобно работать, встроенный сервер! легкую расширяемость достигли используя Python, думаю это плюс выбранной платформы
от себя добавлю, в Mercurial:
- грамотная поддержка "экстерналов" (subrepository) причем штатно как git svn так и самих hg
- контроль доступа к веткам и каталогам файлам
Mercurial лучше подходит для командной разработки в рамках как небольшой так и большой команды, чем git
но с git тоже работал не мало
| | |
|
| |
| 2.46, PereresusNeVlezaetBuggy (ok), 05:02, 07/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Хех. По поводу mercutial для большой команды. [Проработанные и опенсорсные] cистемы code
> review появились?
Для Review Board плагин имеется. Хотя вообще мне самому было бы интересно посмотреть на толковое решение для DVCS - пока что всё виденное (не скажу, что сильно интересовался вопросом) было на post-commit'ах.
| | |
|
| 1.47, Алексей Морозов (ok), 07:58, 07/11/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Ну, в меру толковое решение для git называется Gerrit. У него есть, конечно, свои затыки, но в сравнении с Review Board это просто другой уровень.
| | |
| |
| 2.48, Алексей Морозов (ok), 08:02, 07/11/2011 [^] [^^] [^^^] [ответить]
| +/– | |
Точнее так:
когда я последний раз смотрел на Review Board, он весь строился вокруг концепции патча.
Соответственно, работа с цепочкой изменений, отправленных на ревью, становилась, м-м-м, мягко говоря, неочевидной. Ну, разумеется, предполагается, что в ходе ревью какие-то из присланных ченджсетов в цепочке будут изменены, какие-то вообще могут быть выброшены, ну и так далее.
| | |
| |
| 3.51, PereresusNeVlezaetBuggy (ok), 10:46, 07/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Точнее так:
> когда я последний раз смотрел на Review Board, он весь строился вокруг
> концепции патча.
> Соответственно, работа с цепочкой изменений, отправленных на ревью, становилась, м-м-м,
> мягко говоря, неочевидной. Ну, разумеется, предполагается, что в ходе ревью какие-то
> из присланных ченджсетов в цепочке будут изменены, какие-то вообще могут быть
> выброшены, ну и так далее.
Это зависит от организации процесса... При жёстком требовании использования небольших атомарных коммитов это не проблема. Такое требование имеет свои плюсы в случае обнаружения регрессий уже после коммита - shit happens. Но в более мягкой ситуации, при разработке типичного десктопного приложения - да, будет неудобно.
| | |
| |
| 4.52, Алексей Морозов (ok), 18:55, 07/11/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> При жёстком требовании использования небольших атомарных коммитов это не проблема.
фиче-бранчи на двух-трёх человек становятся чудом.
| | |
| |
| 5.53, PereresusNeVlezaetBuggy (ok), 18:57, 07/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
>> При жёстком требовании использования небольших атомарных коммитов это не проблема.
> фиче-бранчи на двух-трёх человек становятся чудом.
_Иногда_ стабильность важнее скорости вливания фич. :)
| | |
| |
| 6.56, Алексей Морозов (ok), 00:37, 08/11/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> _Иногда_ стабильность важнее скорости вливания фич. :)
В фиче-бранчах-то? Почти никогда. Основная задача фиче-бранча - быть наколбашенным быстро, и не разваливая основное дерево.
| | |
| |
| 7.57, PereresusNeVlezaetBuggy (ok), 03:18, 08/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
>> _Иногда_ стабильность важнее скорости вливания фич. :)
> В фиче-бранчах-то? Почти никогда. Основная задача фиче-бранча - быть наколбашенным быстро,
> и не разваливая основное дерево.
Нет, я имел в виду конечную разрабатываемую систему. Где новые фичи разрабатываются не очень часто, а вот сам процесс ревью довольно жёсткий. Одно дело - видеоплеер у хомячка грохнется, и другое - сбой на конвеере завода или на web-сервисе с посещаемостью на уровне "Яндекса" или "Википедии". Повторюсь, специфика везде своя. :)
| | |
|
|
| 5.54, Алексей Морозов (ok), 19:01, 07/11/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> фиче-бранчи на двух-трёх человек становятся чудом.
... в том смысле, что фиче-бранч предполагает, во-первых, что изменения колбасятся быстро, без ожидания аппрува каждого коммита прежде чем приступить к следующему, а, во-вторых, работу над одним и тем же кодом ведут несколько человек. Соответственно, у них гарантированно будут пересечения по коду и они будут вынуждены корректировать свои коммиты при изменении коммитов где-то в глубине цепочки/дерева.
| | |
|
|
|
| 2.50, PereresusNeVlezaetBuggy (ok), 10:40, 07/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Ну, в меру толковое решение для git называется Gerrit. У него есть,
> конечно, свои затыки, но в сравнении с Review Board это просто
> другой уровень.
Да, это уже смотрится интереснее, спасибо за информацию.
| | |
|
|
