Mercurial vs Git

в stg — ветке

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

Чем rebase или branch --clone не устраивает? И что mq в этом плане дает?

Да и зачем такие сложности? Вылизываешь с помощью stg фичу в отдельной ветке, периодически делаешь ветке rebase на upstream, потом сливаешь ее с основной. Изменения уходят в основной репозиторий. Всё, работа для stg закончена. Если нужен backport, то это уже отдельная работа.

Когда патчи ортогональны веткам, намного меньше проблем.

В рамках ветки ты работаешь с очередью, в рамках репозитория с веткой. Где тут место для проблем?

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

$ stg br different-branch

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

Да. То что не сделав qpop -a, не наложишь патчи на другую ветку, это ограничение. А то что 3 команды вместо одной, да еще и название очереди появляется, это просто неудобство.

Да и зачем такие сложности? Вылизываешь с помощью stg фичу в отдельной ветке

Гг.

Даже команды так назвали, как мне хотелось.

Ты не поверишь:

[alias]
	st = status
	ci = commit
	br = branch
	co = checkout
	di = diff
	lo = log --graph --oneline --decorate --all

Опции тоже назвали, как ты хотел?

Попробую провернуть такое в Git.

И что mq в этом плане дает?

Нет бессмысленной привязки к бранчам.

Вылизываешь с помощью stg фичу в отдельной ветке, периодически делаешь ветке rebase на upstream, потом сливаешь ее с основной. Изменения уходят в основной репозиторий.

Вот это сложности в чистом виде. Тут хватит тупо одного патча.

Где тут место для проблем?

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

Гг.

Подробнее, пожалуйста.

Подробнее, пожалуйста.

Если заводишь фичеветку при наличии очереди патчей, то ты очень странный тип.

Вот это сложности в чистом виде. Тут хватит тупо одного патча.

Для фичи может, а иногда и должен быть, тест. Часто, чтобы откомментировать свои действия, «тупой патч» может быть раз на несколько последовательных патчей. Или тебя слово «фича» смущает?

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

stg rebase вместо hg qpop -a и hg qqueue лишние действия?

В stg можно по-другому? Научи.

Или в культурном обществе всегда принято делать один патч на фичу?

Сначала ты объясняешь, что плохо жить без ветко-специфичных очередей, потом говоришь «вылизываешь в отдельной ветке». Как ты вообще работаешь? Зачем тебе веткоспецифичные очереди, насколько часто ты переключашься между ними и, главное, зачем?

В stg можно по-другому?

Если другие разработчики не решают опубликовать свои фичи в репе, то работаю только с мастером (и то, в последнее время начал подтягивать их как патчи на мастер). Да, одна очередь на всё про все. Только написал один скриптик для пуша, чтоб он её игнорировал.

Сначала ты объясняешь, что плохо жить без ветко-специфичных очередей, потом говоришь «вылизываешь в отдельной ветке».

...с помощью stg

Где противоречие?

Как ты вообще работаешь? Зачем тебе веткоспецифичные очереди, насколько часто ты переключашься между ними и, главное, зачем?

Переключаюсь, когда меняется решаемая задача. Зачем нужны? Так удобно же: не надо помнить куда приложена очередь, не надо делать делать qpop -a, чтобы переключиться, можно положить очередь поверх другой. Как в подобных случаях может помочь mq, я не знаю. Или скажешь, не нужно?

Если другие разработчики не решают опубликовать свои фичи в репе, то работаю только с мастером (и то, в последнее время начал подтягивать их как патчи на мастер). Да, одна очередь на всё про все. Только написал один скриптик для пуша, чтоб он её игнорировал.

А если у тебя несколько патчей в очереди логически связаны, как ты их будешь таскать по этой очереди? Свернешь в один патч? Или ты, в принципе, задачу на отдельные патчи не дробишь?

Попробую провернуть такое в Git.

Не трать время. В git, если ты даже скопируешь файлы, размер репозитория не вырастет (если не считать размер tree и commit объектов).

за счет чего?

В чем разница?

http://git-scm.com/book/en/Git-Internals-Git-Objects http://www.opennet.ru/base/dev/git_guts.txt.html

Основная идея в том, что ссылка на содержимое файла идет не по имени, а по sha1-хешу.

VCS должна просто работать и НЕ ТРЕБОВАТЬ ИЗУЧЕНИЯ. Потому svn продолжает рулить. ИМХО.

Fixed :)

Вы все еще изучаете возможности своей ИДЕ? Тогда мы идем к вам!
С любовью, команда разработчиков Notepad.

VCS должна просто работать и НЕ ТРЕБОВАТЬ ИЗУЧЕНИЯ. Потому svn продолжает рулить. ИМХО.

согласен. Но есть некое «но» - vcs не нужна. Нужно DVCS.

svn != DVCS, и потому не нужно.

Потому svn продолжает рулить.

SVN — это «паровоз» с КПД 10% в эпоху сверхскоростных «электровозов». Очень много танцев и камланий нужно сделать, чтобы правильно сделать merge конкурирующих коммитов. Поэтому коммиты делаются нечасто, проект развивается медленно.

Пара ссылок:

Переход на DVCS, Mercurial

Hg Init: Часть 1. Переобучение для пользователей Subversion

Борьба нешуточная развернулась тоже здесь: http://www.opennet.ru/opennews/art.shtml?num=36226

Очень много танцев и камланий нужно сделать, чтобы правильно сделать merge конкурирующих коммитов

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

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

Гг.

Подробнее, пожалуйста.

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

Просто расскажи, как ты работаешь

Появлась новая задача:

  $ stg br -c newtask
  $ stg new solution
  $ write solution
  $ stg ref

  $ stg new test
  $ write test
  $ stg ref

  $ stg sink

  $ stg new special-case
  $ write special case solution
  $ stg ref

  $ stg br oldtask

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

Еще раз: чтобы не запоминать, куда изначально была приложена очередь, чтобы не снимать патчи при переключении на другую очередь, чтобы была возможность поэкспериментировать, как одна очередь ляжет на другую.

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

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

Причем здесь «простейшая-непростейшая» и сборка мусора? Вопрос о способе хранения и адресации объектов в репозитории.

Забавно:

I wanted to keep a local copy of a kernel repo in our mercurial server. So I cloned the 660M git repo and got a 5GB mercurial repo...

У людей занимающихся абсолютно разными задачами есть потребность изменять одни и те же файлы. И это не измениться никак, товарищ теоретик, ибо эти файлы и должны быть общие.

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

Забавно:

Не, забавно другое:

That said, I never met this extreme difference in other repositories besides the Linux kernel. Yet this is no surprise to me, given that git was especially written to handle that use-case.

Вот это тоже интересно:

git is simply more efficient in storing directory layout than Mercurial, because it:
a) uses a more aggressive compression mechanism, and
b) stores the directory layout of the whole repo in small tree-object nodes instead of one big file.

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

Вот это тоже интересно:

Там всю нить интересно прочитать, не выдергивая цитаты.

SVN — это «паровоз»

Люди жаловались, что на очень больших репозитариях (5 ТБ) git и hg умирают. svn работает.

Плюс ещё какие-то были непонятки с кодировками. В svn мне пользователь создал файл с русским именем - он корректно скачался на клиенты с виндой (где cp1251) и линуксом (причём старым линуксом, где локаль кои-8). Причём это отлично работает как в командной строке, так и в TortoiseSVN. Последний раз, когда я интересовался этим вопросом, у «наследников» с этим были проблемы.

Возможно, сейчас всё это вылечили. Но мне, например, нужно очень сильно подумать, прежде чем переводить на DVCS наш фирменный репозитарий, который ведётся с 2006 года.

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

Прекратите решать за других, что им удобнее.

// А вообще я за меркуриал, да.

Это ты про того который привел 0 формальных критериев о приемке на работу? :)

По теме интересно вас не задевает медленность SVN на таком старом репе? Или там в новых версиях уже все более лучше?

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

А тут вдруг у него попёр язык рекламных заклинаний. «Доверьтесь ему» и др. Такое ощущение, что автор сам в чём-то не уверен.

Не, тут другое. Реклама.

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

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

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

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

мне нравиться.

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

Сборка мусоры нужна совсем не для этого

Да, это я неправильно выразился (давно перестал следить за git). Имелся в виду git-repack.

у git нет GUI уровня TortoiseHg

есть TortoiseGit, только подобная фигня нафиг не нужна.

Тут видно распространение Git и hg https://www.ohloh.net/repositories/compare

Хотите быть маргиналами при том что никаких исключительных фичей не получите - юзайте Hg. Хотите иметь очень мощный и распространенный инструмент - юзайте Git.

TortoiseGit

win only = fail

SmartGit можешь еще попробовать

Я думал, что маргиналы это те, кто использует CVS и SVN. Как жестоко я ошибался!!

Я думал, что маргиналы это те, кто использует CVS и SVN. Как жестоко я ошибался!!

+1, мой мир не будет прежним