Mercurial vs Git

Чем-то кроме черепахи пользуются?

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

??

Цветная лапша лапшой быть не перестает.

так вот, мы на работе пользуеся gitextensions+git source control provider для visual studio (выше приводил ссылку). черепахой почти не пользуемся, потому что она менее удобпа по сравнению с предыдущими двумя.

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

а такие вещи как git bisect удобнее из баша.

Почему git больше распространён, если он только для огромных команд и зверской автоматизации?

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

Ну если бы я выбирал только для себя, то будет git, т.к. уже привычно. Но поскольку инициатива наказывает инициатора, то думается в случае hg последствия будут менее тяжёлыми. Т.к. использую linux только я и никаких СУВ в том месте до сих пор не использовали.

Т.к. использую linux только я и никаких СУВ в том месте до сих пор не использовали.

webdav будет намного проще.

Тред не читал. Самому лень сравнивать. Какая VCS наиболее адекватно на локалхосте справится с блобами на несколько гигов?

На новой работе сейчас cvs...

Они там что ли стукнутые???

Нет.

Кто ж такое убожество использует?

Те, кто переполз на него с RCS 15 лет назад. Вот он для них привычен, всё работает, и ничего люди менять не хотят.

Какая VCS наиболее адекватно на локалхосте справится с блобами на несколько гигов?

rdiffbackup

Use-case R1..Rn тебе понятен? Встроенный язык для более сложных ситуаций.

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

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

Те, кто переполз на него с RCS 15 лет назад. Вот он для них привычен, всё работает, и ничего люди менять не хотят.

я знаю людей с SVN-головного-мозга, тоже страшное зрелище

вижу как они страдают, мучаются, не коммитят неделями...

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

Я вижу одну - трудоемкость.

ну смари, есть гит — нативный, быстрый, гибкий и мощный.

есть меркуриал — пистон, менее быстрый, менее гибкий и менее мощный.

Да ты же наркоман.

Я вижу одну - трудоемкость.

нет задачи - нет трудоемкости. будет задача - приходи, померимся трудоемкостями.

Зато написано про -Wall, -Werror, -O2, -g и другие весьма полезные вещи. Но это же всего лишь иструмент, нахрена про него что-то знать, правда?

нет, неправда. Знать надо, маны читать надо, вот только в мане не написано, что такое оптимизация, как она работает, и зачем нужна. Написано только, что включает -O0, -O1, -O2 и -O3(ещё -Os). Нужное давно уже прописано в Makefile, и думать про это не нужно. А вот команды hg каждый день вбивать приходится. Историю смотреть, пушить, мержить и т.д.

Я разве это утверждал? Наводящий вопрос: Зачем физику знать СТО если есть красивая и стройная теория Ньютона?

знать-то может и надо, вопрос в применяемости. Какому-то оптику теория Ньютона и не нужна наверное. Он уже забыл давно. Как я про -Werror не помню. Юзаю -Wall.

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

У глубоко убежден что лучше TortoiseHg я в жизни ничего не видел, так что не показалось.

Всем добра (Mercurial-а) :)

будет задача - приходи

Я с самого начала дал пример: hg log -r «merge() and file('foo/bar')» означает «ревизии, в которых мержи затрагивали файл foo/bar». Ну или пример из мануала: hg log -r "(keyword(bug) or keyword(issue)) and not ancestors(tag())" означает «ревизии со словами 'bug' или 'issue' в лог-мессагах, не входящие ни в какую помеченную ревизию».

какие упоротые люди пилят этот Mercurial? почему для запуска так широко разрекламированного HTTP-сервера, используется команда serve и ругается на логичное server? где логичность и понятность команд?

почему для запуска так широко разрекламированного HTTP-сервера, используется команда serve

Потому что команды обычно называются глаголами, а не существительными.

Ну и пусть переписывается. Коммиты есть? Есть. В неизменном виде? В неизменном. Что ещё надо-то?

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

В Mercurial история, как правило, остаётся неизменной: её просто незачем менять. А в Git, как в политике, почему-то исторический ревизионизм оказался в моде.

какие упоротые люди пилят этот Mercurial? почему для запуска так широко разрекламированного HTTP-сервера, используется команда serve и ругается на логичное server? где логичность и понятность команд?

иногда стоит пользоваться словарем чтобы понять - serve более логичное имя для этого действия

Посоветуйте годных туториалов для hg, где рассматривается что-то сложнее commit + push.

Держи перевод про Mercurial: http://bacher09.org/hgbook/ru/pdf/hgbook.pdf

вобщем немного поковырявшись никаких приимуществ у Mercurial по сравнению с fossil для домашнего использования\небольших проектов я не нашёл.

вобщем немного поковырявшись

22.02.2013 22:59:53 - 22.02.2013 23:19:25

%)

Спасибо! Хорошая книга, почти что исчерпывающий материал, дает полнейшее представление как работать.

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

Это в каком случае у коммитов меняются хеши?

В случае git rebase: http://habrahabr.ru/post/161009/

ревизии, в которых мержи затрагивали файл foo/bar
ревизии со словами 'bug' или 'issue' в лог-мессагах, не входящие ни в какую помеченную ревизию

чем не устраивает grep, --no-merges, --max-parent=1?

Страшный rebase есть и в hg. mq вообще с историей творит черти что, а с гитом я никогда не делаю слияния, только кромсаю историю через stgit. И именно эти средства избавляют от лапши с которой так безуспешно борется автор первого швабротопика.

Гуй очень удобен, когда делаешь blame, дальше находишь последнюю ревизию интересующей тебя строки, смотришь blame предыдущей ревизии и так несколько раз. В гуе всё это - несколько ленивых кликов мышкой.

Страшный rebase есть и в hg.

Какой? Тот, в результате которого создаётся две головы в центральном репозитории? Он не страшен, поскольку не уничтожаетпереписывает историю: http://habrahabr.ru/post/161009/#comment_5551297

Ещё момент:

Все нормальные плагины к Mercurial, нацеленные на изменение истории коммитов работают только с той историей, которая никуда из локальной машины не ушла… После pull'a с твоей машины кем-нибудь или push на другую менять историю нельзя…

Внезапно, гит даже две головы в удаленной репе не создает, он просто не дает запушить.

Потому что под него есть github?

чем не устраивает grep, --no-merges, --max-parent=1?

Покажи команду.

Потому что под него есть github?

А для Mercurial есть bitbucket и code.google. На битбакете даже можно держать бесплатно кучу приватных реп, если до 5 человек в команде.

Внезапно, гит даже две головы в удаленной репе не создает, он просто не дает запушить.

я не понял, если я создал какой-то коммит, который идёт в разрез с апстримом, то как мне его пушить?

то как мне его пушить?

Внезапно, так же как и в hg. Слиянием или ребейзом.

Внезапно, так же как и в hg. Слиянием или ребейзом.

дык в hg вторая голова создастся, не? Это что, пуллить надо сначала, создавать локально вторую голову и мержить? А если у меня инета нет, и я оттуда(где нет инета) принёс банку на флешке? Мне что, разворачивать вторую репу?

А если у меня инета нет

То как ты собрался пушить?

То как ты собрался пушить?

флеш-нет и бандлы.

Мне что, разворачивать вторую репу?

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

ну например есть два репа А и Б. Я что-то меняю и там и там, но на А нет интернета. Потому я создаю на А бандл, приношу его в Б, а там пушу A → Б. Т.к. Б тоже изменён, получается вторая голова, причём Б это «удалённый», т.к. пушу я прямо из А(точнее из бандла, сделанного на А).

флеш-нет и бандлы.

Да, гит такого не умеет.

Кстати, я не помню, а без клонирования эти головы можно слить?

приношу его в Б,

То есть он уже склонирован? Тогда нет проблем.

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

обычно есть релиз, в котором только багфиксы, и есть current, в котором новые фичи. Потому две головы сами по себе появляются, если я скажем работаю над current, при этом в «главном» репе есть какой-то багфикс, о котором я не знаю, т.к. у меня в репе его ещё нет. Так и получается две головы. Это естественное развитие кода, даже с одним разработчиком. Не? А как у вас?

Кстати, я не помню, а без клонирования эти головы можно слить?

да, конечно. И сделать новый бандл с одной головой, который и унести Б → А.

Это не две головы, это разные бранчи.

То есть он уже склонирован? Тогда нет проблем.

в том-то и дело - пока я возился с A, кто-то изменил Б(возможно я сам, дабы поправить мелкий глюк). Тут фишкка в том, что мне и НУЖНО две головы - одна недоделанная, а вторая - рабочая.

Это не две головы, это разные бранчи.

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