Mercurial vs Git

Кстати, что было пунктом 3?

Это секретный пункт, который знают только git-враги ^_^

Что такого в «плане управления коммитами» умеет git, чего не умеет mercurial или mercurial+mq? И в каких случаях это полезно?

Забыл файл добавить, amend на мелкий фикс. Про mq тоже не все пользователи hg знают.

...в одном рабочем каталоге, да?

А что такого?

«Ты только думаешь, что понял это» (ц)

Для hg я даже так думать не могу.

Не фактор вообще, по крайней мере для меня.

Я же говорю, вкусовщина.

Кстати, что было пунктом 3?

Еще не придумал. :)

Забыл файл добавить, amend на мелкий фикс

В более-менее новом hg есть commit --amend.

...в одном рабочем каталоге, да?

А что такого?

Долго объяснять. Впрочем, mq официально поддерживает несколько очередей.

Так не бывает.

В тот же автомобиль нельзя «просто сел и поехал».

Так не бывает.

Бывает-бывает. Конечно, если ты только с дерева слез и встретил Git - «сесть и поехать» не получится. А если у тебя есть опыт работы с любой VCS, и ты встретил Mercurial - «сел и поехал».

Специально для тебя:

3. http://blogs.msdn.com/b/bharry/archive/2013/01/30/git-init-vs.aspx

Никаких секретов.

Вот Mercurial это как мопед - сел и поехал.

Долго объяснять. Впрочем, mq официально поддерживает несколько очередей.

Только как я понял, одновременно на разных ветках их использовать нельзя. В mq очередь принадлежит репозиторию, в stg — ветке, отсюда и ограничения.

В mq очередь принадлежит репозиторию, в stg — ветке, отсюда и ограничения.

Ты так и не сказал, в чем ограничение.

А если у тебя есть опыт работы с любой VCS, и ты встретил Mercurial - «сел и поехал».

Если workflow не выходит за рамки ci, co, то да. И для git будет также. Если требуется что-то большее, то любой инструмент потребует изучения.

Как в mq на каждой ветке работать со своей очередью? Например, работаешь на одной ветке, у тебя одна очередь, переключился на другую — другая.

Видимо я покорен харизмой Линуса, ничего не могу с собой поделать )

К тому же Git объективно лучше всяких Subversion, а больше мне пока и не надо )

Хотя гуй к нему прикрутить было бы неплохо, да.

К тому же Git объективно лучше всяких Subversion, а больше мне пока и не надо )

Сомнений нет, git >>> svn.

Хотя гуй к нему прикрутить было бы неплохо, да.

Да, такой как TortoiseHg ^_^

То есть как TortoiseGit, ага.

То есть как TortoiseGit, ага.

Вот кстати TortoiseGit штука крутая была еще много лет назад. К великому сожалению, под Linux и другие UNIX-like ОСи этой штуки нет, и видимо не появится, т.к. изначальное не портабельно...

У меня Mercurial 2.0.2

Зачем такое старьё держишь?

> hg --version
Распределенная SCM Mercurial (версия 2.5.1)
(подробнее см. http://mercurial.selenic.com)

(С) 2005-2012 Matt Mackall и другие.
Это свободное ПО; условия распространения см. в исходном коде.
НИКАКИХ ГАРАНТИЙ НЕ ПРЕДОСТАВЛЯЕТСЯ, в том числе на пригодность для
коммерческого использования и для решения конкретных задач.

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

Откуда это утверждение?

Напомнить сколько реп и пользователей на GH? Ты просто неосилятор, признай это.

у маздая тоже 95%, хотя там всё через жопу. Ну и что? Я как-то осилил перенести репу на гите, это возможно, но зачем трахаться-то? Мазохист чё-ли? Ставь венду, чё уж? Будет там тебе cygwin с github'ом.

например, правка коммитов.

правка истории не нужна и вредна. Даже комментов.

вот скажи, ты можешь подтвердить проблему что если hg move сделать над репозиторием с одним сжатым например gz файлом на мегабайт, то при hg move размер папки .hg возрастет в два раза?

проверь пожалуйста, тут дело Mercurialьей чести

а старую версию я держу потому что Ubuntu-вские PPA-версии Mercurial-а и TortoiseHg периодически становятся несовместимыми, пакеты конфликтуют версиями - требуется более старая версия и т.п. - я устал от этого, вот что было в Ubuntu 12.04 - то я и поставил себе и мне хватает

У меня Mercurial 2.0.2

у меня 2.2.2, там если переименовываешь(простым mv), то пишет «файл похоже переименован», и вроде как его просто переименовывает в репе, а не копирует. И кстати, там не копия в репе, а хардлинки, потому сама репа вообще места почти не занимает. А вот с переименованием получается таки копия. ССЗБ - hg не заточен на фильмы и прочее. Оно для текстов короче 1Мб.

вот как оно у меня на Quake2

drb@ksu:~/q$ du -shx .hg
577M	.hg
drb@ksu:~/q$ mv img/Quake2.mdf .
drb@ksu:~/q$ hg addr
добавляется Quake2.mdf
удаление img/Quake2.mdf записывается как переименование в Quake2.mdf (похожесть 100%)
Quake2.mdf: может потребовать до 878 МБ памяти для обработки этого файла
(используйте 'hg revert Quake2.mdf' чтобы отменить запланированное добавление)
drb@ksu:~/q$ hg ci
Quake2.mdf
зафиксирован набор изменений 1:de2ca0e37fd9
drb@ksu:~/q$ du -shx .hg
838M	.hg

таки распухло.

т.е. и при явном hg mv и при addremove - одинаковый результат???

призываю iZEN-а сделать такой же тест с его 2.5.* версией

А если у тебя есть опыт работы с любой VCS, и ты встретил Mercurial - «сел и поехал».

Если workflow не выходит за рамки ci, co, то да.

Даже если выходит.

И для git будет также

Нет.

Если требуется что-то большее, то любой инструмент потребует изучения.

С Mercurial изучения требует концепция DVCS (довольно простая, на самом деле), а с Git - и концепция, и инструмент (который специально написан так, чтобы быть непохожим на другие).

Как в mq на каждой ветке работать со своей очередью?

hg qpop -a; hg co -С different-branch; hg qqueue patches-for-different-branch

т.е. и при явном hg mv и при addremove - одинаковый результат???

угу

drb@ksu:~/q$ du -sx .
1469656	.
drb@ksu:~/q$ hg mv Q2RusSetup.exe Q2RusSetup1.exe 
Q2RusSetup.exe перемещается в Q2RusSetup1.exe
drb@ksu:~/q$ hg ci
Q2RusSetup1.exe
зафиксирован набор изменений 2:7682500d84b4
drb@ksu:~/q$ du -sx .
1636316	.
drb@ksu:~/q$ du -sx Q2RusSetup1.exe 
166752	Q2RusSetup1.exe

hg mv тоже копирует. Впрочем в help так и написано.

А если у тебя есть опыт работы с любой VCS, и ты встретил Mercurial - «сел и поехал».

Если workflow не выходит за рамки ci, co, то да.

Даже если выходит.

смотря куда выходит. Если большие бинарники, то hg не подходит (про git не в курсе).

С Mercurial изучения требует концепция DVCS (довольно простая, на самом деле), а с Git - и концепция, и инструмент (который специально написан так, чтобы быть непохожим на другие).

вот а нейфейхуя было изъёываться?

> ls /tmp/pkg/All/
total 35
drwxr-xr-x  3 igor  wheel    40B 24 фев 18:59 ../
-rw-r--r--  1 igor  wheel    34M 24 фев 18:59 chromium-25.0.1364.97.tbz
drwxr-xr-x  2 igor  wheel    40B 24 фев 18:59 ./

> cd /tmp/pkg/
> hg init

> ls /tmp/pkg
total 1
drwxrwxrwt  11 root  wheel   480B 24 фев 18:59 ../
drwxr-xr-x   2 igor  wheel    40B 24 фев 18:59 All/
drwxr-xr-x   3 igor  wheel   120B 24 фев 18:59 .hg/
drwxr-xr-x   4 igor  wheel    80B 24 фев 18:59 ./

> hg add All/chromium-25.0.1364.97.tbz 
All/chromium-25.0.1364.97.tbz: может потребовать до 109 МБ памяти для обработки этого файла
(используйте 'hg revert All/chromium-25.0.1364.97.tbz' чтобы отменить запланированное добавление)

> du -shx .hg
 16k	.hg

> hg ci
<отредактировал /tmp/hg-editor-ZMAzzb.txt на предмет сообщения фиксации>

> du -shx .hg
 34M	.hg

> mv All/chromium-25.0.1364.97.tbz .
> ls /tmp/pkg
total 35
-rw-r--r--   1 igor  wheel    34M 24 фев 18:59 chromium-25.0.1364.97.tbz
drwxr-xr-x   4 igor  wheel   400B 24 фев 19:02 .hg/
drwxr-xr-x   2 igor  wheel     0B 24 фев 19:06 All/
drwxrwxrwt  13 root  wheel   560B 24 фев 19:06 ../
drwxr-xr-x   4 igor  wheel   120B 24 фев 19:06 ./

> ls /tmp/pkg/All/
total 1
drwxr-xr-x  2 igor  wheel     0B 24 фев 19:06 ./
drwxr-xr-x  4 igor  wheel   120B 24 фев 19:06 ../

> hg addr
удаляется All/chromium-25.0.1364.97.tbz
добавляется chromium-25.0.1364.97.tbz
удаление All/chromium-25.0.1364.97.tbz записывается как переименование в chromium-25.0.1364.97.tbz (похожесть 100%)
chromium-25.0.1364.97.tbz: может потребовать до 109 МБ памяти для обработки этого файла
(используйте 'hg revert chromium-25.0.1364.97.tbz' чтобы отменить запланированное добавление)

> hg log
набор изм-й:   1:72b414bc4cda
метка:         tip
автор:         Игорь
дата:          Sun Feb 24 19:07:13 2013 +0400
сводка:        Второй коммит

набор изм-й:   0:eea269474b32
автор:         Игорь
дата:          Sun Feb 24 19:02:24 2013 +0400
сводка:        Первая фиксация

> du -shx .hg
 69M	.hg

— из-за перемещения файла между каталогами хранилище растёт.

Вот сейчас проект попроще, там еще не так много тестовых файлов.

>du -shx .hg
127M    .hg

>du -shx .hg/store/data/tests
87M     .hg/store/data/tests

>hg -q mv tests replays
>hg ci -m renamed

>du -shx .hg
151M    .hg

>du -shx .hg/store/data/replays
22M     .hg/store/data/replays

>du -shx replays
71M     replays

из-за перемещения файла между каталогами хранилище растёт

это ужасно... моя жизнь не будет такой как прежде, я считал что в Mercurial это работает, так везде написано =(

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

Дедупликацию в Mercurial не помешало бы запилить. Или это оставить файловой системе? ;)

в stg — ветке

Такое поведение сильно выбешивает. Постоянно приходится патчи с ветку на ветку утягивать. Когда патчи ортогональны веткам, намного меньше проблем.

Считай +22M на пустом месте

отвёрткой тоже гвозди плохо заколачивать. ЕМНИП и автор писал, что hg для вороха мелких сырцов. А бинарники лучше в .hgignore. С сырцами нормально справляется, пример большого репа - https://developer.mozilla.org/en-US/docs/Developer_Guide/Source_Code/Mercurial

Т.ч. проблема в тебе.

Если большие бинарники, то hg не подходит (про git не в курсе).

Ну, для больших бинарей есть largefiles и специализированные системы типа Alien Brain.

вот а нейфейхуя было изъёываться?

Линус ненавидит CVS (и SVN тоже), и старался делать так, чтобы было непохоже.

Я не понял, ты тоже негодуешь что гит невозможно сложная система?

не сложная, а неудобная. Я его осилил, и иногда юзаю - приходится.

Это не так. Миллионы хомячков бороздят просторы.

а миллиарды мух жрут говно. И что?

Миллионы хомячков бороздят просторы.

clone, checkout, commit, push - это не git, а гитхаб.

Ну, для больших бинарей есть largefiles и специализированные системы типа Alien Brain.

вот именно.

Линус ненавидит CVS (и SVN тоже), и старался делать так, чтобы было непохоже.

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

И что?

Поднимись по ветке повыше, там будет ответ.

clone, checkout, commit, push - это не git, а гитхаб.

Когда такие же неосиляторы hg наезжают на git это очень смешно.

отвёрткой тоже гвозди плохо заколачивать. ЕМНИП и автор писал, что hg для вороха мелких сырцов.

А чем текстовые описания сценариев для тестирования отличаются от «сырцов», особенно если считать что они на каком-то своем специфическом языке описаны? Часть из них создается полностью вручную с нуля в текстовом редакторе, более сложные (а их всегда больше в тестовой базе) генерируются из каких-то внешних сложных моделей.

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

Ни у svn, ни у git репозиторий не пухнет так как у hg при переносе тестов в другую директорию. Как по-другому более правильно для hg нужно решать эту задачу?

А чем текстовые описания сценариев для тестирования отличаются от «сырцов», особенно если считать что они на каком-то своем специфическом языке описаны? Часть из них создается полностью вручную с нуля в текстовом редакторе,

попробуй нагенерировать хотя-бы мегабайт осмысленного текста.

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

ну и на кой их хранить в VCS? Если их _люди_ не пишут и не читают?

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

не верю я, что ты ручками генеришь миллионы букв текста. А не ручками - эти «неручки» и храни.

Ни у svn, ни у git репозиторий не пухнет так как у hg при переносе тестов в другую директорию. Как по-другому более правильно для hg нужно решать эту задачу?

уже сказал: .hgignore.

Ни у svn, ни у git репозиторий не пухнет так как у hg при переносе тестов в другую директорию

А у вас перекидывание многомегабайтных файлов между каталогами - обычный юзкейс?

А у вас перекидывание многомегабайтных файлов между каталогами - обычный юзкейс?

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

ну и на кой их хранить в VCS? Если их _люди_ не пишут и не читают?

Каждое изменение в коде может привести к изменению решения для каких-то тестов, эти изменения постоянно отслеживаются и просматриваются при разработке (есть специальное графическое приложение для удобного просмотра изменений в тестах). Часто изменения в тестах очень небольшие и можно даже по diff файлу все понять.

При коммите нужно обновлять решения у тестов, чтобы код был согласован с решениями в тестах. Где еще тогда хранить тесты с решениями, если не в VCS?

И для git будет также

Нет.

Да :) Через gui так, вообще, разницы не заметишь.

Если требуется что-то большее, то любой инструмент потребует изучения.

С Mercurial изучения требует концепция DVCS (довольно простая, на самом деле), а с Git - и концепция, и инструмент (который специально написан так, чтобы быть непохожим на другие).

Непожим на svn и cvs? Причем тогда здесь «концепция dvcs»?

Как ты hg освоил? Статей не читал, в маны не заглядывал? После прочтения про dvcs, у тебя в голове сразу сложился стройный набор команд и был это выхлоп hg help?

hg qpop -a; hg co -С different-branch; hg qqueue patches-for-different-branch

$ stg br different-branch

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

Тогда это ерунда. На скорость эти данные не влияют.

Непожим на svn и cvs? Причем тогда здесь «концепция dvcs»?

SVN не хватает только команд push и pull, чтобы стать DVCS (и да, на основе SVN сделана как минимум одна Ъ-DVCS).

Как ты hg освоил? Статей не читал, в маны не заглядывал?

Я практически ничего не читал конкретно о Mercurial (да и нечего было читать во времена 0.[78]); _но_ Mercurial очень близко соответствовал абстрактной DVCS в вакууме, с которой я был отлично знаком (после опыта с Arch, OpenCM, Monotone, и статей о BitKeeper). А Git был вещью в себе, и сначал Линус даже отмазывался, что git не предназначен для непосредственного использования - только под слоем того, что называлось porcelain.

После прочтения про dvcs, у тебя в голове сразу сложился стройный набор коман

Еще раз: к началу 2005 года с концепциями и набором команд DVCS было всё ясно, дело было только за реализацией. Кто ж мог предвидеть, что самая популярная примет вид угребищного Git.

hg qpop -a; hg co -С different-branch; hg qqueue patches-for-different-branch

$ stg br different-branch

Ты _это_ называешь «ограничением»?

При коммите нужно обновлять решения у тестов, чтобы код был согласован с решениями в тестах. Где еще тогда хранить тесты с решениями, если не в VCS?

хорошо. Считай, что hg не подходит для твоей задачи. Структура репы hg такова, что там, как я понял, переименование в принципе невозможно. Им пожертвовали при проектировании, причём вполне сознательно. Потому там mv чисто для галки. IRL оно отсутствует. За то обычные юзкейсы быстрее и лучше работают. Я вот тоже в окно не вхожу - пятый этаж. Неудобно. А вот в обычной ФС нельзя получить файлы, которые начинаются на a, b и c. Надо взять весь список, и его отсортировать. Иначе никак. И версии как копии, и никак иначе.

Как ты hg освоил?

можно я отвечу? Я хотел VCS сам писать. К счастью, ртуть уже написали, причём именно так, как оно я задумал. Даже команды так назвали, как мне хотелось. Мне автору что, морду разбить или спасибо сказать? ☺