[РЕШЕНО] mercurial (hg) - вытягивание изменений из анонимной ветки

[watashiwa_daredeska]

а я пишу:
2. hg push
т.е. заталкиваю изменения в удалённый репозиторий. без всяких слияний.

Мы ведь уже выяснили, что без merge hg будет ругаться и не примет. Или Вы говорите о случае, когда перекладываете свою работу по слиянию на плечи тимлида и плодите горынычей?

после pull ревизия tip указывает на последний коммит, вне зависимости от того, кто его сделал.

Ну вот, а Вы говорили, что tip соответствует Вашему рабочему каталогу.

Я не очень понимаю, что тут нелогичного?

Тут нет ничего нелогичного, если не пользоваться Вашим определением:

tip это как раз и есть текущая рабочая директория.

Ибо не есть.

Может, у нас с Вами разное представление о том, что такое «рабочий каталог»?

[drBatty]

А опыт подсказывает мне, что merge надо делать насколько возможно раньше

почему? пусть будет, не вижу причин сразу всё мержить, что только можно...

>Так что, ключевой вопрос: зачем откладывать merge и накапливать [возможно] несовместимые изменения, которые потом надо будет мержить?

потому-что изменения будут в большинстве своём совместимые, ибо разные кодеры работают над разными частями проекта. нестыковки конечно возможны, но согласитесь - довольно редки. Нестыковки могут возникнуть лишь если один из кодеров поменяет под себя какую-то абстракцию низкого(или наоборот - высокого) уровня, да ещё и так, что эта абстракция ВНЕЗАПНО станет несовместимой с другим кодом. Но это порушит не только наш новый код, но и множество старого кода. Если наш новый код совместим со старым, и код другого кодера - тоже, то в большинстве случаев наши модули будут совместимы друг с другом, ну и слияние соответственно будет нужно лишь при подготовке релиза, когда все наши модули станут работать в продакшене.

я сделаю сначала pull, а потом посмотрю, что-же это за новые ревизии, и стоит-ли делать мне merge

А, post-code-review уже после того, как код в центральном репозитории… И что Вы сделаете, если не сто́ит? Будете создавать змеев горынычей в общем репозитории?

это не "post", а "pre" - змей горыныч посл pull будет в моём локальном репозитории, и в большинстве случаев, вторая чужая голова мне не будет мешать, а просто будет висеть в ознакомительных целях, что-бы я писал код, который когда-нибудь без проблем автоматически сольётся с чужим.

Так вот, в приведенной статье как раз описана автоматизация update. При публикации в «рабочий репозиторий» запускаются хуки, которые обновляют и перезапускают всё, что нужно.

как-то там всё слишком запутанно... если честно - мало что понял.

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

в hg такое можно и не делать - оно получается само по себе.
ни pull, ни push не затрагивают содержимое рабочего каталога, но тем не менее позволяют как вытягивать, так и заталкивать изменения. А в каталоге можно всё удалить.
в принципе в этом есть смысл, особенно если у разработчиков инет есть от случая к случаю, а на bare инет есть 24/7/365.

Хм… hg это позволяет?

это Linux позволяет - удалите все файлы кроме ./.hg, и поставьте на каталог права 0555 - команда update не сможет выполниться, т.к. в таком каталоге нельзя создавать файлы.
может и по другому можно. в принципе, можно попросту запретить доступ на этот сервер иначе, кроме как через mercurial..

Да, но почему вариант второго кодера захламляет мою ветку лишними головами? Почему при pull'е варианта второго кодера перемещается tip моей ветки, хотя я еще даже не решил, буду ли его мержить и как? Почему третий разработчик при взгляде на эту ветку впадает в ступор, не зная какую голову этого змея горыныча нужно сейчас рубить?
В git'е мне, по крайней мере, всё понятно: коммиты второго кодера имеются и помечены отдельной меткой, так что понятно, как до них добраться в случае нужды. Моя ветка, HEAD и рабочий каталог остаются нетронутыми, пока я сам их не трону. Третий разработчик, который смотрит на мою ветку, видит ее голову (одну и только одну), и у третьего разработчика не возникает сомнений, в каком положении находится разработка и откуда можно и нужно ветвить свои изменения.

тогда вам необходимо использовать именованные ветки. А если вы вдвоём пилите одну и ту-же ветку - то что тут странного?
К тому-же, если вы выполняете только pull в процессе работы, то ваши ревизии никто кроме вас не видит, и когда вы закончите, вы можете сделать наконец pull+merge, и слить свою ветку с маинстримом. Причём сольёте вы её _локально_, чего никто тоже не увидит. И если всё хорошо, вы можете смело запушить свою работу. В принципе, pull вы можете сделать и раньше, и не один раз, это никак не повлияет на маинстрим. В маинстриме появятся ваши изменения только после push'а.

Это очень временная ситуация

ну не такая уж и временная.

>и даже при этом, имя ссылается на один и только один файл. Тут же получается две абсолютно неразличимые (для треьего разработчика) головы у одной ветки.

почему "неразличимые"? они от разных авторов. И опять повторю - если вы сливаете ветки локально, то для третьего разработчика будет одна ветка, которая _когда-то_ разделилась, а _потом_ опять соединилась. Если вы, или второй разработчик сможете решить свои разногласия (причём решать их вовсе не обязательно в главном репозитории, вполне можно в вашем, или в репозитории второго кодера, а третий этого и не увидит, он увидит, что конфликт был, но успешно разрешился).

>При том, что удалять ревизии в hg нельзя, и клеймо раба метка ветки пожизненная, вообще непонятно, что с этой ситуацией делать, если я, например, не хочу мержить.

ну вот метку ветки можно и сменить. И ветку можно закрыть, чтоб не маячила в списке веток. Ну будет у вас тупик, ну и что?

вот здесь сказано иное:
QUOTE
If there are multiple heads in a repository, only one of them is the tip.

внесу ясность: действительно, tag tip только один. Это такая голова, которая заканчивает текущую ветку. Однако, если вы переключитесь не другую ветку, tip станет другим.

Т.о. вы можете вытянуть (hg pull) ревизии с другого репозитория, и tip у вас будет стоять на другой ветке, однако, если вы закоммитете изменения, то tip перескочит на вашу ветку. Текущее состояние рабочего каталога (точнее, то, которое было на последнем _вашем_ коммите) обозначено символом @, а вот tip на самом деле может и не совпадать с @.
И при коммите изменения отсчитываются вовсе не от tip'а, а от @, которая может лежать на другой ветке. Короче - у каждой ветки свой tip. Причём hg update tip обнавляет до последнего tip'а который и показывается, а вот hg update обновляет до того tip'а, который может не совпадать с тегом tip, если тег tip не на текущей ветке.

Все эти сложности возникают только с именованными ветками.

1. в каждом репозитории может быть несколько branch·
2. в каждом branch можте быть несколько head·
3. только один из head может быть tip-ом·
4. так сколько же в репозитории может быть tip? один? или их количество равно количеству branch?

1. да
2. да
3. да. С оговоркой: один из тех, кто на этой ветке.
4. tip'ов ровно столько, сколько именованных веток. Однако тег tip присвоен только последнему из tip'ов. Он может не совпадать с tip'ом текущей ветки (который обозначен собакой @ )

[drBatty]

рад за mercurial, что хоть с тэгами они не придумали чего-то «интуитивно понятного»·

дык и веток у них всего две:
1. default
2. stable
ИМХО именованных веток и должно быть очень мало.

докумантация вам противоречит: http://mercurial.selenic.com/wiki/Branchin...med.29_branches
хотя, судя по написанному там про git, вполне могу вам поверить, что и про mercurial там тоже бред написан:

не совсем. "анонимные ветви" в hg на самом деле имеют имя. Если у вас есть ветка release, то разделив её вы получите ветвление, и две головы. И обе будут иметь имя release. Не смотря на название они не будут "анонимными".

в этом и плюс git-а — устроено внутри всё настолько элементарно, что разобраться труда не составляет·

дык я не разбирался ни с тем, ни с другим.

[watashiwa_daredeska]

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

Это слишком сложно для меня. Мне есть о чем думать, кроме беспроблемного слияния когда-нибудь в будущем. Я уж лучше сразу солью и продолжу дальше думать и работать над нужными вещами. Но тогда мне нужна всякая фигня «для ознакомления».

тогда вам необходимо использовать именованные ветки. А если вы вдвоём пилите одну и ту-же ветку - то что тут странного?
К тому-же, если вы выполняете только pull в процессе работы, то ваши ревизии никто кроме вас не видит, и когда вы закончите, вы можете сделать наконец pull+merge, и слить свою ветку с маинстримом. Причём сольёте вы её _локально_, чего никто тоже не увидит.

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

ну вот метку ветки можно и сменить.

Как?

почему "неразличимые"? они от разных авторов.

Потому что тогда надо указывать что-то вроде: «мою текущую работу бери из ветки такой-то, репозитория такого-то, только бери последнюю мою версию, а не tip, а то там такая фигня бывает». Без этого пояснения нифига не понятно. В git'е же если ветка, то всё однозначно, даже если у меня есть несмерженные чужие ветки release, свои ответвления и т.п.

это Linux позволяет - удалите все файлы кроме ./.hg, и поставьте на каталог права 0555 - команда update не сможет выполниться, т.к. в таком каталоге нельзя создавать файлы.

Это совсем не наш метод. Есть hg update не может сделать то, что должен, он должен завершиться с ошибкой, что может сломать скрипты.
Чем-то мне это напоминает борьбу с iexplore.exe в какой-то старинной винде: винда сама его возрождала, если удалить руками; чтобы удалить окончательно, на его место клался пустой iexplore.exe и с него убирались вообще все права для всех :)

ИМХО именованных веток и должно быть очень мало.

А как совместно работать над большой экспериментальной функциональностью, которую пока ни в default, ни в stable нельзя?

[drBatty]

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

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

working copy появляется там, где сейчас тимлидер

Как всё сложно-то. А без тимлидера никак?

легко. любой разработчик (даже который в RO) может сделать свою working copy.

Флейм, троллинг и «да ты кто такой?» в общем репозитории с неудаляемым мусором? Отличная организация работы :)

какая команда - такой и репозиторий.
А неудаляемый мусор - это ещё и огромная ответственность.

Это обязательно делать тимлидеру?

нет. но если разработчики не могут договориться друг с другом - то без тимлидера не обойтись. Если могут - они смержат и без главного репозитория ;)

А что, пушить надо обязательно в репозиторий тимлидера? Бедный, несчастный гипотетический Линус Торвальдс, пользующийся hg :)

нет конечно. пуште куда хотите, рано или поздно всё окажется у тимлидера. только не сразу. ЕМНИП у Линуса как раз такая система - предлагаются коммиты лейтенантам, и они их себе pull'ят. А потом пушат Линусу. Разве не так?

всё это, я надеюсь, вы и сами знаете, но тогда непонятно, для чего написано процитированное…

однако ваши репозитории делятся на "общедоступные" где более одного разраба пушит, и на "локальные". А в hg все одинаковые - все глобальные.
Ещё у вас есть bare. А в hg нету. Там любой можно использовать как bare.

В случае же hg всё начинается сразу с довольно сложных сущностей с нетривиальным поведением.

да. но ими-же и кончается. просто с самого начала надо понять, что локальный репозиторий - это всего-лишь отображение глобального, и это "анонимное ветвление" на самом деле очень логичная и понятная вещь - как ещё отобразить ситуацию, когда у первого кодера файл имеет одно содержимое, а у второго - другое? Причём эта ситуация вполне повседневная и обыденная.

[drBatty]

Это слишком сложно для меня. Мне есть о чем думать, кроме беспроблемного слияния когда-нибудь в будущем. Я уж лучше сразу солью и продолжу дальше думать и работать над нужными вещами. Но тогда мне нужна всякая фигня «для ознакомления».

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

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

в идеологии я не силён. (:
за то это удобно и просто.

Потому что тогда надо указывать что-то вроде: «мою текущую работу бери из ветки такой-то, репозитория такого-то, только бери последнюю мою версию, а не tip, а то там такая фигня бывает». Без этого пояснения нифига не понятно. В git'е же если ветка, то всё однозначно, даже если у меня есть несмерженные чужие ветки release, свои ответвления и т.п.

tip как раз и будет последней версией, если вы конечно не работаете сразу с двумя именованными ветками, а они по вашим-же словам "не подходят". Они вправду не подходят ни для чего, кроме как для разделения проекта на части (обычно release/current, может кому-то и ещё третья ветка нужна, типа unstable). Вот и будет у вас своё анонимное ответвления из current, с которым вы и будете работать. Чем плохо-то?

Как?

hg branch имя
ведь изначально всего одна ветка - default, а потом её имя меняют.
Правда, в назидание останется голова старой ветки. Как я пронял - навсегда. Потому больше трёх веток делать не нужно, а то в старых головах запутаемся.

Это совсем не наш метод. Есть hg update не может сделать то, что должен, он должен завершиться с ошибкой, что может сломать скрипты.
Чем-то мне это напоминает борьбу с iexplore.exe в какой-то старинной винде: винда сама его возрождала, если удалить руками; чтобы удалить окончательно, на его место клался пустой iexplore.exe и с него убирались вообще все права для всех :)

я, честно говоря даже и не задумывался. Наверное есть какой-то способ, надо погуглить. Хотя зачем? Если мне можно делать push & pull, то зачем мне лезть туда в shell, и выполнять там в shell'e разные hg update? Если этот удалённый репозиторий нужен лишь для pull & push, то какой смысл там делать что-то ещё?
ну можно там запустить hg serve, и будет общедоступный репозиторий ReadOnly. А push можно по ssh сделать (тем, кому можно).

А как совместно работать над большой экспериментальной функциональностью, которую пока ни в default, ни в stable нельзя?

в анонимной ветке из default. Вы даже можете это всё пушить в "главный" репозиторий, что-бы все видели, что вы там творите.
конечно, после hg pull, разработчику придётся сказать hg update -rN, где N - номер ревизии Вашего tip'а. А то tip может перепрыгнуть на другую ветвь default.

[watashiwa_daredeska]

однако ваши репозитории делятся на "общедоступные" где более одного разраба пушит, и на "локальные".

Это условное деление. Моё личное. В общедоступном репозитории могут появиться изменения без моего участия, а в личном — нет.

а в hg все репозитории концептуально одинаковы

В git'е тоже одинаковы, просто не каждому разрешено в каждый каталог ФС писать :)

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

С одной. Но голов две. И одна из этих голов — не моя, но она волюнтаристски прихватизировала мою tip.

hg branch имя

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

в анонимной ветке из default.

конечно, после hg pull, разработчику придётся сказать hg update -rN, где N - номер ревизии Вашего tip'а.

OMFG! Back to CVS! Номера и никаких имен :( Скажите, а есть какое-нибудь общедоступное соглашение, типа того, что номера ревизий более-менее стабильных веток должны делиться на 3? Ах, черт, эти номера-то ведь локальные… Совсем печаль.

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

WHAT? Ветвление — одна из самых вкусняшек нормальных VCS. Это начали понимать еще во времена SVN. Веток должно быть много, ветки должны легко создаваться и удаляться. Иначе это бред сивой кобылы и CVS, а не нормальная современная VCS.

да. но ими-же и кончается.

С моей т.з. это приговор — в морг. Однако, mercurial еще держится, потому что ими-таки не кончается. Самое вкусное в hg накостылено расширениями, включая bookmarks и graphlog.

это "анонимное ветвление" на самом деле очень логичная и понятная вещь

Не спорю. Именно поэтому в git нет ничего, кроме «анонимных веток» с т.з. mercurial. Это очень просто, логично и удобно, особенно когда у них есть имена :)

[sash-kan]

а в чём опасность матюков? ну может у вас такой проект, в котором коммиты каждые 5 минут и Over9000 разрабов, тогда да...

Опасности нет, просто привычка, да; выработанная в проектах с частыми коммитами. И естественно, это нужно, в основном, в ситуациях с общим репозиторием.

кстати, вполне здравая привычка для любой ситуации·
к примеру:
я постоянно пользуюсь своими репозиториями с нескольких машин·
только я один, но с нескольких·
и, естественно, на любой из этих машин я сначала сделаю git pull, чтобы получить в working copy актуальную картину, а уж потом начну что-нибудь коммитить (и, тем более, push-ить)·

[kamre]

hg pull == git fetch
hg update == git merge
git pull == git fetch + git merge == hg pull + hg update

а однокомандного аналога git pull в mercurial, насколько мне известно, нет·
(разве что существует какой-нибудь plugin по этому поводу)·

Код: Выделить всё

hg help pull:
...
options:
 -u --update                 update to new branch head if changesets were pulled

неужели mercurial не умеет делать bare-репозитории?

Код: Выделить всё

hg help clone:
...
options:

 -U --noupdate           the clone will include an empty working copy (only a repository)

[kamre]

так сколько же в репозитории может быть tip? один? или их количество равно количеству branch?

Код: Выделить всё

hg help tip:
...
    The tip revision (usually just called the tip) is the changeset most recently added to the repository (and therefore the most recently changed head).

    If you have just made a commit, that commit will be the tip. If you have just pulled changes from another repository, the tip of that repository becomes the
    current tip. The "tip" tag is special and cannot be renamed or assigned to a different changeset.

[sash-kan]

4. tip'ов ровно столько, сколько именованных веток. Однако тег tip присвоен только последнему из tip'ов. Он может не совпадать с tip'ом текущей ветки (который обозначен собакой @ )

Т.о. вы можете вытянуть (hg pull) ревизии с другого репозитория, и tip у вас будет стоять на другой ветке, однако, если вы закоммитете изменения, то tip перескочит на вашу ветку. Текущее состояние рабочего каталога (точнее, то, которое было на последнем _вашем_ коммите) обозначено символом @, а вот tip на самом деле может и не совпадать с @.
И при коммите изменения отсчитываются вовсе не от tip'а, а от @, которая может лежать на другой ветке. Короче - у каждой ветки свой tip. Причём hg update tip обнавляет до последнего tip'а который и показывается, а вот hg update обновляет до того tip'а, который может не совпадать с тегом tip, если тег tip не на текущей ветке.

не совсем. "анонимные ветви" в hg на самом деле имеют имя. Если у вас есть ветка release, то разделив её вы получите ветвление, и две головы. И обе будут иметь имя release. Не смотря на название они не будут "анонимными".

всё, мой парсер окончательно сломался…
лучше я оставлю разбирательство с mercurial-ом до следующей жизни·
есть надежда, что в ней мне достанется чуть больше интуиции и я таки смогу понять:
чем tip отличается от tag tip;
чем working copy отличается от tip;
сколько tip-ов может быть в репозитории;
сколько tag tip-ов может быть в репозитории;
чем unnamed branch отличается от anonymous branch;
чем named branch отличается от anonymous branch;
почему branch может быть то anonymous branch, то named branch;
и т.д. и т.п.

спасибо за внимание…

[drBatty]

Это условное деление. Моё личное. В общедоступном репозитории могут появиться изменения без моего участия, а в личном — нет.

вот я про то и говорю - в hg сам принцип такой, что "репозиторий" - это глобальная абстракция. Потому в моём образе репозитория появляются чужие изменения без моего участия.

В git'е тоже одинаковы, просто не каждому разрешено в каждый каталог ФС писать :)

это уже вопрос не относящийся к DVCS.

С одной. Но голов две. И одна из этих голов — не моя, но она волюнтаристски прихватизировала мою tip.

tip - суть отражения последнего коммита. В силу того, что ртуть глобальная, то если вася сделал commit 5 минут назад, а вы час назад, то естественно tip будет указывать на васин коммит, а не на ваш. Это вполне естественно и правильно. На ваш локальный последний коммит указывает собака @.

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

hg branch не может изменить ревизию (в частности имя ветки), потому она создаёт новую ревизию, с новым именем ветки.

Код: Выделить всё

@  changeset:   8:5f274405f943
|  branch:      current
|  tag:         tip
|  parent:      6:8c62a1378de1
|  user:        drBatty from ksu <drbatty@drbatty.ru>
|  date:        Mon Sep 26 07:33:00 2011 +0400
|  summary:     другие изменения
|
| o  changeset:   7:34e799e001cb
|/   branch:      current
|    user:        drBatty from ksu <drbatty@drbatty.ru>
|    date:        Mon Sep 26 07:30:07 2011 +0400
|    summary:     изменения
|
o  changeset:   6:8c62a1378de1
|  branch:      current
|  user:        drBatty from ksu <drbatty@drbatty.ru>
|  date:        Mon Sep 26 07:26:57 2011 +0400
|  summary:     branch current
|
o  changeset:   5:081bedbfe2ac
|  parent:      3:af3c8d21b620
|  user:        drBatty from ksu <drbatty@drbatty.ru>
|  date:        Sun Sep 25 23:13:24 2011 +0400
|  summary:     y=

я присвоил ревизии №5 имя current, что привело к созданию ревизии №6.

OMFG! Back to CVS! Номера и никаких имен :( Скажите, а есть какое-нибудь общедоступное соглашение, типа того, что номера ревизий более-менее стабильных веток должны делиться на 3? Ах, черт, эти номера-то ведь локальные… Совсем печаль.

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

WHAT? Ветвление — одна из самых вкусняшек нормальных VCS. Это начали понимать еще во времена SVN. Веток должно быть много, ветки должны легко создаваться и удаляться. Иначе это бред сивой кобылы и CVS, а не нормальная современная VCS.

я имею ввиду - именованных веток должно быть две-три. А неименованных - хоть Over9000.

С моей т.з. это приговор — в морг. Однако, mercurial еще держится, потому что ими-таки не кончается. Самое вкусное в hg накостылено расширениями, включая bookmarks и graphlog.

видимо вы что-то таки не поняли :(

и, естественно, на любой из этих машин я сначала сделаю git pull, чтобы получить в working copy актуальную картину, а уж потом начну что-нибудь коммитить (и, тем более, push-ить)·

дык pull, или таки pull+merge?
или у вас pull это pull+merge?
(я кстати тоже так делаю. Если есть возможность. А если нет - не делаю)

[drBatty]

чем tip отличается от tag tip;

tip == ревизия, где был сделан последний коммит.
Не "локально последний", как в гите, а просто последний. Естественно, tip может прыгнуть после pull, если посл. коммит сделали не вы.
Это если именованная ветка одна.
Если именованных веток две, то очевидно, "tip'ов" тоже два, т.к. в каждой ветке можно сделать свой посл. коммит.
Однако, tag tip всё равно один. И именно на него обновляется проект по команде hg update tip.
Однако, по команде hg update обновляется не до tag tip, а до последнего коммита текущей именованной ветки (этот коммит тоже является некоторым образом tip'ом, хотя и не имеет такого тега).

чем working copy отличается от tip;

tip == последний сделанный коммит. Очевидно, что если этот коммит сделали НЕ ВЫ, то и ВАША working copy может быть совсем другой. Даже если ВЫ там ничего не меняли.

сколько tip-ов может быть в репозитории;

tag tip может быть всего один. Однако в каждой именованной ветке есть свой посл. коммит, который тоже можно считать условно tip'ом. Т.к. именно на него обновляет hg update без параметра.

чем unnamed branch отличается от anonymous branch;

этого я и сам не знаю.

чем named branch отличается от anonymous branch;

каждая ревизия имеет имя ветки. По умолчанию имя ветки default, и оно не показывается в логе.
В моём прошлом посте видно ветвление (6->7,8), причём это именно анонимное ветвление внутри (именованной) ветки current.

почему branch может быть то anonymous branch, то named branch;

branch всегда named. А вот ветвление может быть как анонимным, так и именованным.
1. при анонимном ветвлении обе ветки имеют одно и тоже имя, и отличаются только содержимым (обычно файлами в рабочем каталоге). Анонимное ветвление происходит в hg само по себе, в случае, если одна ревизия изменяется двумя разными способами. (например мы два раза отредактировали один и тот-же файл, причём из одного начального состояния. Ну к примеру написали sed -i 's/a/b/' file.txt, потом hg commit, hg update ПРОШЛОЕ_СОСТОЯНИЕ, и потом sed -i 's/a/x/' file.txt, hg commit.
2. при именованном ветвлении изменения worcking copy не происходит (обычно).
Ещё раз посмотрите мой пример: ревизия №5 имеет имя default (которое не показано), ревизия №6 имеет имя current. Однако, если мы посмотрим hg heads, мы увидим, что №5 == голова. Это последняя ревизия ветки default. А значит мы можем вернуться к ней (hg update default) и продолжить эту ветвь:

Код: Выделить всё

@  changeset:   9:ddbbbe45fdf0
|  tag:         tip
|  parent:      5:081bedbfe2ac
|  user:        drBatty from ksu <drbatty@drbatty.ru>
|  date:        Tue Sep 27 08:05:32 2011 +0400
|  summary:     продолжение default
|
| o  changeset:   8:5f274405f943
| |  branch:      current
| |  parent:      6:8c62a1378de1
| |  user:        drBatty from ksu <drbatty@drbatty.ru>
| |  date:        Mon Sep 26 07:33:00 2011 +0400
| |  summary:     другие изменения
| |
| | o  changeset:   7:34e799e001cb
| |/   branch:      current
| |    user:        drBatty from ksu <drbatty@drbatty.ru>
| |    date:        Mon Sep 26 07:30:07 2011 +0400
| |    summary:     изменения
| |
| o  changeset:   6:8c62a1378de1
|/   branch:      current
|    user:        drBatty from ksu <drbatty@drbatty.ru>
|    date:        Mon Sep 26 07:26:57 2011 +0400
|    summary:     branch current
|
o  changeset:   5:081bedbfe2ac
|  parent:      3:af3c8d21b620
|  user:        drBatty from ksu <drbatty@drbatty.ru>
|  date:        Sun Sep 25 23:13:24 2011 +0400
|  summary:     y=
|

тут мы видим именное ветвление - ревизия №5 расходится на две ветки - current & default.

[drBatty]

чем unnamed branch отличается от anonymous branch;

unnamed bransh == branch default

[kamre]

всё, мой парсер окончательно сломался…
лучше я оставлю разбирательство с mercurial-ом до следующей жизни·

На самом деле там все просто и понятно, только изначально оно отличалось от того, что в git.

Вся история представляется в виде графа ревизий, при этом граф ациклический. Ревизии в некотором связном подграфе с одним истоком (ревизия на которой создана ветка) могут относиться к определенной именованной ветке. Таким образом ветка в mercurial это просто отдельный подграф ревизий, в нем может быть несколько голов (ревизий без потомков).

Каждый раз, когда делается коммит, создается новая ревизия, при этом для ревизии сохраняется та ветка, которая была для текущей ревизии (или первая ревизия при merge).

В принципе все эти именованные ветки (имена глобальные, одинаковые во всех клонах) похожи на то, как было с ветками в svn/cvs, только внутри каждой именованной ветки (в том числе и default) можно создавать несколько голов (анонимные ветки внутри именованной).

[sash-kan]

drBatty
kamre
спасибо за ваши старания объсянить·
к сожалению, они породили лишь ещё больше вопросов·
но я уже не хочу в них разбираться, так как главное я и так знал, и вы лишь подтвердили это знание:
архитектура репозиториев git проще архитектуры репозиториев mercurial·
если отталкиваться от приведённого kamre рисунка, то вот так та же картина выглядит в git·
из неё, надеюсь, видно, что branch — это верхушка серии коммитов·
и серия эта начинается с самого-самого начала·
по-моему, именно отсутствие этой простой и прозрачной концепции и привело к той усложнённости, которую можно наблюдать в mercurial:
branch с именем default почему-то называется безымянным;
предпочтительно малое количество branch-ей;
сущности, про которые я так и не понял, как их правильно называть — то ли head-ы, то ли анонимные branch-и, до которых не доберёшься по человечески понятному имени [1];
невозможность посмотреть всю историю от определённой верхушки до самого-самого начала·

[1] как вообще обмениваться информацией про эти сущности между разработчиками? «смотри мои коммиты, начиная с коммита с хэшем таким-то и вверх по истории (если будешь смотреть завтра или послезавтра, я туда ещё кучу коммитов добавлю и, естественно, не могу сказать, какие у них будут хэши)»? всё-таки проще сказать «смотри ветку „feature123“»? по этому имени будут доступны все коммиты, добавленные в этом ответвлении и завтра, и послезавтра, и через год (пока branch жив)·

[drBatty]

я хаутушку напишу.
Вы потом скажите - годная, или нет.
если годная -здесь будет.

кстати...
моя подпись
ЧСХ-учебник про сед - всегда hg

такие дела

[kamre]

архитектура репозиториев git проще архитектуры репозиториев mercurial·
если отталкиваться от приведённого kamre рисунка, то вот так та же картина выглядит в git·

На самом деле в git с ветками получается проще. Только я еще не до конца прояснил для себя вопросы с local/remote branches, и с тем что именно убивает git gc. Но иметь нормальные имена для всех heads (branches в git) это должно быть удобно.

сущности, про которые я так и не понял, как их правильно называть — то ли head-ы, то ли анонимные branch-и, до которых не доберёшься по человечески понятному имени

Когда я работал с mercurial, то постоянно пользовался локальными номерами ревизий (прям по аналогии с svn). Но пару раз разводил такое количество анонимных веток и перемерживал их потом, что даже запутывался Делать именованную ветку, которая навсегда и во всех клонах, не очень хотелось, а экспериментов было много всяких. Тогда не было еще bookmarks, поэтому давать временные имена таким веткам было вообще нельзя. Можно было в разных клонах экспериментировать, но я постоянно таскал repo с работы домой и обратно на флэшке, поэтому с кучей веток было удобнее вроде.

[Portnov]

remote branches отличаются от local только тем, что git знает, откуда они взялись и умеет по команде получать из источника или пропихивать в источник изменения более-менее автоматически (git fetch origin утянет изменения во всех отслеживаемых ветках репозитория origin). А git gc удаляет объекты, до которых нельзя добраться, двигаясь от ссылок в .git/refs/* по ссылкам на родителей. Например, это коммиты, которые были когда-то сделаны в каких-то боковых ветках, которые (ветки) не были вмержены ни в одну из ныне живущих веток, а были удалены.