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

[drBatty]

вы изменяете в копии файл и (внезапно) в исходном репозитории он тоже изменяется…

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

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

репозитории в mercurial _действительно_ независимы. Единственная зависимость - клон помнит своего родителя, что позволяет его не указывать во многих командах. т.е.

Shell

$ hg clone repo1 repo2 # создаём клон repo2 из repo1 $ cd repo2 $ vim ... # что-то там меняем в клоне... $ hg push # пушим изменения из repo2 в repo1.

Впрочем, можно и записать КУДА пушить явно. Как и в других командах.

[watashiwa_daredeska]

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

Ничего не понимаю © Один из Колобков. Так соответствует или может не совпадать?

как я вас понял, git выполняет некоторые действия ВМЕСТО ФС. Т.е. подменяет функции ФС.

Нет. Он использует схожие принципы дизайна.

ну в hg это несколько другой случай - вы попытались удалённо создать новую голову, т.е. удалённо пытаетесь развернуть разработку проекта в другую сторону (точнее создать развилку).

Не суть важно, что происходит физически. Важнее то, что если кто-то уже сделал изменение от исходной точки, то мне надо сделать pull+merge (или git pull) прежде, чем делать push. Это всё, о чём я говорю — не больше, но и не меньше.

как hg определяет, двигать tip, или нет. Если мы просто смотрим на развитие проекта

Я простой программист, у меня нет спец. образования по физике торсионных полей. Не могли бы Вы пояснить для тупых, как hg определяет: просто мы смотрим или не просто, если команды одинаковые?

Если-бы вы поименовали свою ветку, то никаких изменений не произошло

Проверил с именованной веткой. Та же хрень, только после hg up tip еще и ветка изменилась.

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

Годный сценарий. В git так тоже можно, правда лучше для этого не git fetch использовать, а git remote update.

3б. я могу сделать hg pull, и тогда развилка появится у меня.

Ну вот, о чем я и говорю. pull перед push. Я не знаю, как в hg, но в git безопасно, а потому и проще делать pull перед push не дожидаясь матюков от git при push.

[drBatty]

Однако, pull+merge — наиболее часто используемый сценарий.

а вот и нет: вот самый простой сценарий:

1. я включаю компьютер, и что-то правлю в проекте. Пишу, тестирую, делаю коммиты...
2. наконец я выполняю hg push
...
А дальше возможны варианты:

3а. у меня была последняя ревизия главного репозитория. Причём пока я правил, ничего в нём не изменилось. В этом случае никаких вопросов не будет - все мои коммиты перенесутся в главный репозиторий. Мне (или тимлидеру) достаточно будет выполнить там hg up что-бы применить мои изменения.

3б. репозиторий изменился. Тут я могу сделать развилку в главном репозитории hg push -f
тогда развитие проекта пойдёт моим путём (старый путь сохранится, и тимлидер может слить эти пути).

3в. кроме того, после неудачи с push я могу взять новые изменения, и самостоятельно осуществить слияние.

потому, pull+merge вовсе не основная операция.
В случае наличия главного репозитория (классическая схема), основная операция

Shell

local$ # редактирование/отладка local$ hg commit local$ hg push main$ hg update

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

[sash-kan]

Всё очень просто...

вы не поверите, но бывает ещё проще: не делать того, чего не просили явно·
пока я не скажу — создай новую ветку в удалённом репозитории, она не будет создана·
такая логика у git-а·

А вот вся история клона изначально хранится как хардлинки.

не знаю, что именно подразумевается в mercurial под словом история, но в .git/objects хранятся _все_ объкты, которыми манипулирует git — blob, tree, commit, tag·
существующие объекты неизменяемы, новые коммиты лишь добавляют новые объекты, не изменяя существующих·
собственно, если изменить любой из объектов, изменится его хэш-сумма, а она отражена в имени файла, содержащего объект, а значит, любой файл, имя которого не соответствует хэш-сумме содержимого — это мусор·
в mercurial, видимо, всё построено внутри несколько иначе (судя по вашим словам)·

[drBatty]

Ничего не понимаю © Один из Колобков. Так соответствует или может не совпадать?

соответствует в момент коммита, или в момент апдейта.

Не суть важно, что происходит физически. Важнее то, что если кто-то уже сделал изменение от исходной точки, то мне надо сделать pull+merge (или git pull) прежде, чем делать push. Это всё, о чём я говорю — не больше, но и не меньше.

я и не говорю про физику - вы _не должны_ делать pull+merge перед push. Вы делаете push, и _если_ не получается, в _можете_ сделать pull+merge, а можете пойти другим путём.

Я простой программист, у меня нет спец. образования по физике торсионных полей. Не могли бы Вы пояснить для тупых, как hg определяет: просто мы смотрим или не просто, если команды одинаковые?

Проверил с именованной веткой. Та же хрень, только после hg up tip еще и ветка изменилась.

ну может и так. я никогда не пишу hg up tip, я пишу просто hg up. В полном соответствии с документацией, tip берётся из текущей ветки. Естественно, он остаётся на месте в _моей_ ветке, даже если кто-то изменил какую-то другую.
Если мне нужно поменять ветку я так и пишу: hg up имя_ветки.

Ну вот, о чем я и говорю. pull перед push. Я не знаю, как в hg, но в git безопасно, а потому и проще делать pull перед push не дожидаясь матюков от git при push.

а в чём опасность матюков? ну может у вас такой проект, в котором коммиты каждые 5 минут и Over9000 разрабов, тогда да... А у меня вряд-ли такое будет, скорее всего всё отлично запушится без всяких матюков. Потому pull+merge в 99% случаев делать не нужно. В оставшемся 1% может мне захочется не pull+merge, а push -f?
В hg безопасны все три варианта.

[sash-kan]

3а. у меня была последняя ревизия главного репозитория. Причём пока я правил, ничего в нём не изменилось. В этом случае никаких вопросов не будет - все мои коммиты перенесутся в главный репозиторий. Мне (или тимлидеру) достаточно будет выполнить там hg up что-бы применить мои изменения.

вот с этого места нельзя ли поподробнее?
«выполнить там hg up» — где это _там_?

[drBatty]

вы не поверите, но бывает ещё проще: не делать того, чего не просили явно·
пока я не скажу — создай новую ветку в удалённом репозитории, она не будет создана·
такая логика у git-а·

дык и в hg точно также: в удалённом репозитории новая ветка не создаётся, если явно не сказать hg push -f.
но почему вы считаете, что push это обязательно новая ветка?

не знаю, что именно подразумевается в mercurial под словом история, но в .git/objects хранятся _все_ объкты, которыми манипулирует git — blob, tree, commit, tag·

мне честно говоря всё равно, КАК они хранятся. Они хранятся в файлах, в каталоге ./.hg
Причём в этом каталоге большинство файлов - хардлинки, если это клон. Остальное меня мало волнует.

существующие объекты неизменяемы, новые коммиты лишь добавляют новые объекты, не изменяя существующих·
собственно, если изменить любой из объектов, изменится его хэш-сумма, а она отражена в имени файла, содержащего объект, а значит, любой файл, имя которого не соответствует хэш-сумме содержимого — это мусор·
в mercurial, видимо, всё построено внутри несколько иначе (судя по вашим словам)·

честно говоря, я не знаю, и не очень хочу знать, КАК это всё хранится.
Я знаю следующее:
1. hg хранит ревизии - состояние рабочего каталога в момент коммита.
2. каждая ревизия имеет свой уникальный хеш (кроме того она имеет (возможно не уникальный) номер для удобства, может иметь тег, и может принадлежать к именованной ветке. Хеш зависит ото всех файлов, от тегов, от имени ветки, от автора ревизии, от её описания, и от времени создания ревизии.
3. Каждая ревизия имеет одного родителя. Кроме начальной ревизии (сирота), и ревизий, которые возникли в результате слияния (два родителя).
4. Каждая ревизия имеет ровно одного потомка, кроме голов, которые могут не иметь потомков (а могут и иметь).
5. ревизии создаются 1 раз и никогда не уничтожаются. Потому файлы тоже существуют всегда. Причём не только файлы, но и все их версии. Если засунуть в репозиторий бинарник в 1Гб, он так там и будет болтаться всю жизнь :(

существующие объекты неизменяемы, новые коммиты лишь добавляют новые объекты, не изменяя существующих·
собственно, если изменить любой из объектов, изменится его хэш-сумма, а она отражена в имени файла, содержащего объект, а значит, любой файл, имя которого не соответствует хэш-сумме содержимого — это мусор·

в hg, в каталоге .hg/store/data/ лежат бинарные файлы. Например если в проекте есть файл 1.c, то будет файл .hg/store/data/1.c.i. Там содержится информация о начальном файле, и все его изменения.

[sash-kan]

я и не говорю про физику - вы _не должны_ делать pull+merge перед push. Вы делаете push, и _если_ не получается, в _можете_ сделать pull+merge, а можете пойти другим путём.

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

[drBatty]

3а. у меня была последняя ревизия главного репозитория. Причём пока я правил, ничего в нём не изменилось. В этом случае никаких вопросов не будет - все мои коммиты перенесутся в главный репозиторий. Мне (или тимлидеру) достаточно будет выполнить там hg up что-бы применить мои изменения.

вот с этого места нельзя ли поподробнее?
«выполнить там hg up» — где это _там_?

в главном репозитории. Т.е. я меняю файл 1.с, делаю коммит(локально) и push(от себя в главный репозиторий). Ревизия переходит в главный репозиторий, но файл в этом репозитории НЕ меняется. Нужно перейти в этот главный репозиторий, и в нём выполнить hg up.

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

почему-же для watashiwa_darede... "проще делать pull+merge перед push"? А мне - сложнее?

[sash-kan]

дык и в hg точно также: в удалённом репозитории новая ветка не создаётся, если явно не сказать hg push -f.

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

но почему вы считаете, что push это обязательно новая ветка?

я этого не говорил·
наоборот: push — это должна быть только одна, конкретная, текущая ветка· пока явно не сказано "запушить в ветку такую-то"·
разработчики mercurial, естественно, придерживались несколько иной логики·

4. Каждая ревизия имеет ровно одного потомка, кроме голов, которые могут не иметь потомков (а могут и иметь).

а как же ветвление?

[sash-kan]

в hg, в каталоге .hg/store/data/ лежат бинарные файлы. Например если в проекте есть файл 1.c, то будет файл .hg/store/data/1.c.i. Там содержится информация о начальном файле, и все его изменения.

да-да, вспоминаю· обсуждали уже это·
если файл 1.c изменился, то перезаписывается весь файл .hg/store/data/1.c.j
а в .git/objects в этом случае создаётся _новый_ файл, но сущестующие не изменяются·
git действительно проще устроен, а значит, надёжнее·

[drBatty]

ага, и создаётся «ветка второго сорта»·
т.н. «безымянная ветка»·
и таких «веток без имени», как я понял, может быть много·

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

и «добраться» до них, как я понял, можно только по хэш-сумме·

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

и она, естественно, меняется по мере того, как ветка развивается·

нет. хеш ревизии _никогда_ не меняется.

очень удобно, да·
главное, очень интуитивно·

просто я ещё сам не разобрался до конца...
но всё очень просто и логично.

я этого не говорил·
наоборот: push — это должна быть только одна, конкретная, текущая ветка· пока явно не сказано "запушить в ветку такую-то"·
разработчики mercurial, естественно, придерживались несколько иной логики·

она и есть - одна, текущая :)
с десятью головами :)
Это уже от команды зависит, от самих кодеров...

а как же ветвление?

да... может быть сколько угодно потомков...
это я ошибся. Один "прямой", и остальные - результаты слияния.

да-да, вспоминаю· обсуждали уже это·
если файл 1.c изменился, то перезаписывается весь файл .hg/store/data/1.c.j
а в .git/objects в этом случае создаётся _новый_ файл, но сущестующие не изменяются·

и что? вы думаете это даст экономию места/размера?
тесты не дают однозначного ответа что компактнее/быстрее.

git действительно проще устроен, а значит, надёжнее·

почему "проще"? просто мне лень разбираться во внутреннем устройстве того и другого.

[sash-kan]

3а. у меня была последняя ревизия главного репозитория. Причём пока я правил, ничего в нём не изменилось. В этом случае никаких вопросов не будет - все мои коммиты перенесутся в главный репозиторий. Мне (или тимлидеру) достаточно будет выполнить там hg up что-бы применить мои изменения.

вот с этого места нельзя ли поподробнее?
«выполнить там hg up» — где это _там_?

в главном репозитории. Т.е. я меняю файл 1.с, делаю коммит(локально) и push(от себя в главный репозиторий). Ревизия переходит в главный репозиторий, но файл в этом репозитории НЕ меняется. Нужно перейти в этот главный репозиторий, и в нём выполнить hg up.

вы держите working copy в репозитории общего пользования???
неужели mercurial не умеет делать bare-репозитории?

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

почему-же для watashiwa_darede... "проще делать pull+merge перед push"? А мне - сложнее?

пардон, не понял вашей мысли·
watashiwa_daredeska, насколько понмю, говорил об одном из workflow — т.е., когда несколько разработчиков работают с одной веткой·
естественно, прежде чем что-то отправлять в эту ветку, нужно сначала получить оттуда изменения и слить со своими· иначе будет «отлуп»·
git pull — это команда, выполянющая два действия (если есть желание, их можно выполнять и по-отдельности): git fetch (получить новые объекты, не затрагивая working copy) и git merge (объединить полученные объекты со сделанными локально изменениями)·

противоположный workflow — каждый работает со своими ветками в общем репозитории·
в чужие ветки никто ничего не коммитит, значит, git pull перед git push можно смело не делать·

[sash-kan]

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

о, да, спасибо, что напомнили про эту лебединую песню интуитивной понятности·
номера ревизий в _распределённой_ vcs!
тут и не знаешь, то ли плакать, то ли смеяться·

А как иначе?

например, по имени·
просто и со вкусом·
и даже интуицию не надо привлекать — одной логики вполне достаточно·

и она, естественно, меняется по мере того, как ветка развивается·

нет. хеш ревизии _никогда_ не меняется.

я говорил про ветку, а не про отдельный коммит из этой ветки·

она и есть - одна, текущая :)
с десятью головами :)

чёрт, эта разница в терминологии с ума может свести·
если я правильно понял применяемую вами терминологию, то когда я говорю «ветка» вы представляете себе что-то совсем другое, нежели я·
я под веткой (branch) понимаю то, что есть в git:
именованная верхушка последовательности коммитов, каждый потомок в которой несёт в себе хзш-сумму предка (внутри последовательности могут быть «утолщения», произошедшие от слияний, в этом случае верхний в «утолщении» коммит имеет двух (и более) предков, а нижний — двух (и более) потомков)·
«безымянных» последовательностей в нормальной ситуации просто не бывает — физически такое, конечно, может произойти, если, например, удалить ветку, но после gc весь этот мусор будет удалён·

почему "проще"?

потому что так задумывался·

[drBatty]

>вы держите working copy в репозитории общего пользования???

нет. я её там не держу. как я уже говорил, нету никакого "главного" репозитория, нет и "общего пользования". working copy появляется там, где сейчас тимлидер, который осуществляет слияние конфликтующих анонимных веток (если такие есть, а такие будут только в том случае, если есть два(или больше) разработчика, каждый из которых имеет собственное мнение об одном и том-же вопросе), а также собирает проект из полученной work. copy, и запускает релиз в продакшен. Естественно удобно, если тимлидер работает за компьютером, который 24/7 в Сети, и в который можно в любой момент запушить изменения.

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

угу, вижу как хабралюди прикручивают кучу непонятных костылей/хуков - http://habrahabr.ru/blogs/Git/127213/
что-бы выполнить задачу, которой в hg попросту НЕ возникает :(
в чём фишка bare?

>пардон, не понял вашей мысли·
>watashiwa_daredeska, насколько понмю, говорил об одном из workflow — т.е., когда несколько разработчиков работают с одной веткой·
>естественно, прежде чем что-то отправлять в эту ветку, нужно сначала получить оттуда изменения и слить со своими· иначе будет «отлуп»·

неестественно.
можно отправить без всякого получения (в hg), и никакого отлупа скорее всего не будет. Т.е. в hg допустимо просто push, без всяческих pull+merge, и это есть основной workflow. Отлуп будет лишь в случае конфликта, когда в данную ветку другой разработчик успел запушить свои изменения. Вот тут придётся либо самому разрабу сливать ветки, либо отдать эту работу тимлидеру, который решит, какой вариант будет в итоге.

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

ага. начинаю понимать логику: hg pull - это _одно_ действие: вытягивание новых ревизий из другого репозитория. В принципе, если на обоих компах имеется доступ в Сеть, то можно всегда начинать работу с hg pull, а уж потом редактировать файлы проекта. В этом случае мы получим локальное ветвление, в том случае, если другой разработчик тоже внёс некоторые изменения. Но тогда workflow будет:
1. hg pull
2. редактирование файлов
3. hg commit
4a. hg push если нет конфликтов
4b. hg merge+hg push, если получилась развилка
4c. hg push -f, если получается развилка, но кодер настаивает на своём варианте, и делегирует право решать тимлидеру. Тогда развилка появится в удалённом репозитории.
Какой из вариантов выбрать(4a || 4b/4c) - подскажет коммит на шаге №3.
Workflow pull+merge пригодится лишь в случае, если кодер не сделал шаг №1, и потерпел неудачу на шаге №4a (на шаге №3 он не сможет узнать об этом фэйле, т.к. он не вытянул свежих изменений. Впрочем, он может потерпеть неудачу даже если вытянет - если кто-то запушит ревизии на шаге №2)

противоположный workflow — каждый работает со своими ветками в общем репозитории·
в чужие ветки никто ничего не коммитит, значит, git pull перед git push можно смело не делать·

такой вариант естественно тоже поддерживается в hg.

о, да, спасибо, что напомнили про эту лебединую песню интуитивной понятности·
номера ревизий в _распределённой_ vcs!
тут и не знаешь, то ли плакать, то ли смеяться·

а что такого? В hg номер ревизии - просто ярлык у этой ревизии. Я смотрю лог, и если мне нужно слить (с tip)

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

| @  changeset:   4:3f33bed5178a
|/   user:        drBatty from ksu <drbatty@drbatty.ru>
|    date:        Sun Sep 25 23:11:18 2011 +0400
|    summary:     added 2.c
|

я просто пишу

Shell

hg merge -r4

Это короче чем
hg merge 3f33bed5178a
вот и всё.

например, по имени·
просто и со вкусом·
и даже интуицию не надо привлекать — одной логики вполне достаточно·

конечно можно и по имени, например, если у меня есть две ветки:
1. current
2. release
То я могу (находясь в ветке release) выполнить hg merge current, что приведёт к тому, что все изменения из current перейдут в release, и у меня появится новая ревизия в ветке release (новый релиз).
Кроме того, на любую ревизию я могу повесить теги, и обращаться к ревизиям (в частности сливать) по этим тегам.
Вот посмотрите, какие теги вешают сами разрабы hg: http://selenic.com/hg/tags
ИМХО очень удобно и логично.

я говорил про ветку, а не про отдельный коммит из этой ветки·

Именованная ветка в hg имеет совсем другое значение - это просто последовательность ревизий, которая имеет собственное имя. У ветки в hg нет хеша, потому он и не меняется :) На самом деле, "именованная ветка" в hg это тот-же tag, разница в том, что tag не наследуется, а branch наследуется, т.е. прямой потомок ветки release тоже принадлежит к ветке release. В hg у каждой ревизии(кроме начальной) может быть 1 или 2 родителя - если мы находимся в ветке release (это текущая ветка), и пишем hg merge current, то прямой(первый) родитель у получившейся ревизии будет ревизия из release, и сама ревизия будет принадлежать к ветке release.

чёрт, эта разница в терминологии с ума может свести·
если я правильно понял применяемую вами терминологию, то когда я говорю «ветка» вы представляете себе что-то совсем другое, нежели я·

тут вы видимо абсолютно правы.

именованная верхушка последовательности коммитов, каждый потомок в которой несёт в себе хзш-сумму предка (внутри последовательности могут быть «утолщения», произошедшие от слияний, в этом случае верхний в «утолщении» коммит имеет двух (и более) предков, а нижний — двух (и более) потомков)·

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

Вот пример: мы имеем анонимную ветку

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

@  changeset:   5:081bedbfe2ac
|  tag:         tip
|  parent:      3:af3c8d21b620
|  user:        drBatty from ksu <drbatty@drbatty.ru>
|  date:        Sun Sep 25 23:13:24 2011 +0400
|  summary:     y=
|

и хотим сделать её именной веткой current

Shell

$ hg branch current рабочий каталог помечен как ветвь current $ hg commit

Теперь ветка стала именной:

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

@  changeset:   6:8c62a1378de1
|  branch:      current
|  tag:         tip
|  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=
|

Если мы сделаем изменения, имя ветки наследуется:

Shell

$ echo >>1.c $ hg commit

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

@  changeset:   7:34e799e001cb
|  branch:      current
|  tag:         tip
|  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=
|

«безымянных» последовательностей в нормальной ситуации просто не бывает — физически такое, конечно, может произойти, если, например, удалить ветку, но после gc весь этот мусор будет удалён·

ну "безымянных" веток в hg тоже не бывает.
Если в моём примере вернутся к ревизии 6:8c62a1378de1

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

$ hg up -r6
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

затем внести другие изменения и сделать коммит

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

$ echo "// ---" >>1.c
$ hg commit
создана новая голова

то мы увидим такую картину:

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

@  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

Видно, что ветка current теперь с двумя головами.

потому что так задумывался·

повторяю - как оно задумывалось, и как это всё реализовано физически - меня волнует слабо. В этом плюс hg - нет нужды знать, как это всё хранится/работает. Достаточно усвоить понятие "ревизия", и понятие "репозиторий". Причём последним может быть вообще один файл (банка(bundle)), или скажем компьютер доступный по ssh, или в простейшем случае другой каталог, или компьютер доступный по http (достаточно выполнить hg serve, и компьютер превращается в hg-сервер, правда ReadOnly, зато с web интерфейсом. Вот с таким). Разницы между репозиториями никакой нет - все одинаковые, не смотря на свою физическую реализацию.

[watashiwa_daredeska]

потому, pull+merge вовсе не основная операция.

Конечно. Основная операция — commit. Я говорил о том, что pull+merge — основная комбинация для pull. Конечно, Вы привели случай с эпизодическим подключением к Сети, я принимаю этот сценарий, хотя сам редко бываю в такой ситуации.

ну может и так. я никогда не пишу hg up tip, я пишу просто hg up. В полном соответствии с документацией, tip берётся из текущей ветки.

Ага, так tip еще и не один. И все они соответствуют рабочему каталогу, да?

соответствует в момент коммита, или в момент апдейта.

Остановившиеся часы два раза в сутки показывают верное время. Если я говорю, что HEAD в git'е соответствует тому коммиту, от которого отсчитываются изменения в рабочем каталоге, то это означает, что ВСЕГДА соответствует, а не только в некоторые моменты.

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

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

[watashiwa_daredeska]

угу, вижу как хабралюди прикручивают кучу непонятных костылей/хуков - http://habrahabr.ru/blogs/Git/127213/
что-бы выполнить задачу, которой в hg попросту НЕ возникает :(

А как решается задача публикации сайта при пуше в hg?

в чём фишка bare?

Это репозиторий без рабочего каталога.

[watashiwa_daredeska]

Видно, что ветка current теперь с двумя головами.

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

[drBatty]

Я говорил о том, что pull+merge — основная комбинация для pull.

даже при постоянном соединении, эта комбинация почти никогда не встречается.
1. pull
2. изменение проекта
3. возможно - слияние.
Именно потому не нужна команда pull+merge. Она как раз подойдёт в случае отключённого интернета:
1. изменения проекта
2(как только появилась сеть) pull+merge
Вот только, в момент шага 2 неизвестно, нужно-ли тут pull+merge, или достаточно push? Проще попробовать сразу сделать push, и уже после, если надо, pull+merge+push.

Ага, так tip еще и не один. И все они соответствуют рабочему каталогу, да?

да. Скажем в моей ветке my tip соответствует моему каталогу в момент последнего моего коммита.
В ветке other tip соответствует рабочему каталогу другого разработчика, в момент его последнего коммита. Всё очень просто. Это если мы пилим разные ветки. Если мы пилим одну и ту-же, то tip тоже один - того, кто последний запушил изменения.

Остановившиеся часы два раза в сутки показывают верное время. Если я говорю, что HEAD в git'е соответствует тому коммиту, от которого отсчитываются изменения в рабочем каталоге, то это означает, что ВСЕГДА соответствует, а не только в некоторые моменты.

tip в hg тоже соответствует тому состоянию рабочего каталога, от которого отслеживаются изменения. Тоже - всегда.

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

ну ситуации с разными репозиториями я даже рассматривать не стану, лично мне этого (пока) не нужно, вполне хватает одного репозитория на всё про всё. Второй репозиторий ИМХО может понадобится лишь в том случае, если я хочу делать коммиты, которых не будет в истории проекта. Такой нужды пока не возникает. И вот в ситуации с общими репозиториями я не понимаю, зачем может понадобится pull+merge, если можно сделать в начале работы pull, а в конце - push. Нужда в слиянии возникнет лишь в том случае, если кто-то во время моей работы запушит свои новые ревизии. В этом _частном_ случае мой push провалится, также как и в git'е. Но ничего страшного тут нет, и мало того, я скорее всего не стану делать pull+merge, я сделаю сначала pull, а потом посмотрю, что-же это за новые ревизии, и стоит-ли делать мне merge с отключённым мозгом, на автомате. Или есть смысл сначала подправить свой код. В точности также как это делает движок форума (в т.ч. и этот) - вы давите "отправить" (push), и только в _некоторых_ случаях встречаетесь с сообщением об ошибке "тема изменилась", вам предлагается отредактировать своё сообщение с учётом новых постов. Это ведь логично? Согласитесь, было-бы странно, если-бы _каждый раз_ вы-бы при нажатие "отправить" вываливались в предпросмотр, где будет ваше новое сообщение (не отправленное) + чужие новые посты + чужие старые? Вот движок форума работает в данном случае как hg, а не как git.

А как решается задача публикации сайта при пуше в hg?

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

Это репозиторий без рабочего каталога.

хм... А в чём фишка репозитория без рабочего каталога? В hg это можно реализовать очень просто - необходимо и достаточно не разрешать выполнение локально (для этого репозитория) команды hg update. тогда содержимое рабочего каталога никогда не будет изменяться (что не помешает делать push & pull в/из него).
Только я всё равно не понимаю, какие плюсы у этой сущности?

[drBatty]

Видно, что ветка current теперь с двумя головами.

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

это инерция мышления: вполне нормальна ситуация, когда мы имеем двух разработчиков, и каждый вносит в один и тот-же файл взаимоисключающие изменения.
Очевидно, в этой ситуации мы просто обязаны получить две версии одного и того-же файла с одним именем. Даже не две версии, а три:
1. то что было изначально.
2. вариант первого кодера.
3. вариант второго кодера.
такая ситуация возможна и в ФС: самый простой пример, когда мы обновляем работающую программу. В этом случае на диске получаются два файла с одним именем:
1. старая программа, которая сейчас работает.
2. новая программа, которая заменила удалённую старую.
Можете сами проверить, всё именно так и происходит. Мало того, это вовсе не обязательно должна быть программа - достаточно лишь того, что-бы файл был открытым. Его можно успешно удалить, и создать такой-же с тем-же именем. Получится два файла, с одинаковыми именами, в одном месте ФС, но с разными inode'ами, и с разным содержимым. Это вполне нормальная ситуация для любой многопользовательской ОС. Почему, кстати, я и называю маздай - однопользовательской ОС.

В hg вы можете посмотреть не только номера/хеши, которые никому ничего не говорят, и служат лишь ссылками на ревизии, но и автора+описание ревизии+дата, которые вам наверное скажут о многом. А номер/хеш нужен лишь для ссылки на ревизию.Причём довольно редко, ибо в 80% случаев вам нужна ревизия tip из текущей ветки, и в 19% случаев - tip из какой-то другой ветки.

[watashiwa_daredeska]

даже при постоянном соединении, эта комбинация почти никогда не встречается.
1. pull
2. изменение проекта
3. возможно - слияние.

Ну, я как-то практикую другую схему:
1. Изменение.
2. Синхронизация. Делится на:
2a. fetch
2b. merge
Делать fetch, потом изменять, а потом делать слияние — для меня что-то довольно странное.

Скажем в моей ветке my tip соответствует моему каталогу в момент последнего моего коммита.

Но после pull изменений в этой ветке — уже не соответствует ни Вашему каталогу в момент Вашего коммита, ни каталогу в его текущем состоянии. А значит, с моей т.з., не соответствует им вообще.

tip в hg тоже соответствует тому состоянию рабочего каталога, от которого отслеживаются изменения. Тоже - всегда.

Не всегда. Если после pull перемещается tip, затем я делаю изменения в каталоге и hg commit, то появится новый head, не от tip, в котором не будет изменений, которые были в tip.

И вот в ситуации с общими репозиториями я не понимаю, зачем может понадобится pull+merge, если можно сделать в начале работы pull, а в конце - push.

Если я веду собственную разработку в той же ветке, то pull создаст вторую голову. Если я не сделаю merge, то эта вторая голова так и останется отдельной. И push обломится. Поэтому мне все равно придется делать merge. А опыт подсказывает мне, что merge надо делать насколько возможно раньше, так зачем ждать обломившегося push, если мы уже сделали pull и можем merge'ить?
Либо, не делая merge, я после pull переключаюсь на вытянутую ветку (hg up, который тоже не является для Вас частым сценарием) и теряю (хорошо, в отсутствие gc в hg, бросаю на некоторое время) свои наработки в другой голове. Либо опять-таки hg merge и, согласно моему опыту, желательно раньше, чем позже.
Так что, ключевой вопрос: зачем откладывать merge и накапливать [возможно] несовместимые изменения, которые потом надо будет мержить?

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

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

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

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

хм... А в чём фишка репозитория без рабочего каталога?

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

необходимо и достаточно не разрешать выполнение локально (для этого репозитория) команды hg update.

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

тогда содержимое рабочего каталога никогда не будет изменяться

И зачем тогда этот каталог?

[watashiwa_daredeska]

когда мы имеем двух разработчиков, и каждый вносит в один и тот-же файл взаимоисключающие изменения.
Очевидно, в этой ситуации мы просто обязаны получить две версии одного и того-же файла с одним именем. Даже не две версии, а три:
1. то что было изначально.
2. вариант первого кодера.
3. вариант второго кодера.

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

такая ситуация возможна и в ФС: самый простой пример, когда мы обновляем работающую программу. В этом случае на диске получаются два файла с одним именем:
1. старая программа, которая сейчас работает.
2. новая программа, которая заменила удалённую старую.

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

[sash-kan]

Скажем в моей ветке my tip соответствует моему каталогу в момент последнего моего коммита.
В ветке other tip соответствует рабочему каталогу другого разработчика, в момент его последнего коммита.

вот здесь сказано иное:

If there are multiple heads in a repository, only one of them is the tip.

в общем, чем больше я читаю про mercurial, тем больше каши в голове·
в каждом репозитории может быть несколько branch·
в каждом branch можте быть несколько head·
только один из head может быть tip-ом·
так сколько же в репозитории может быть tip? один? или их количество равно количеству branch?

[sash-kan]

Вот посмотрите, какие теги вешают сами разрабы hg: http://selenic.com/hg/tags
ИМХО очень удобно и логично.

согласен· это общепринятая практика: http://repo.or.cz/w/autoconf.git/tags·
рад за mercurial, что хоть с тэгами они не придумали чего-то «интуитивно понятного»·

[sash-kan]

ну "безымянных" веток в hg тоже не бывает.

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

Both Git and Mercurial support unnamed local branches.

ну нету в git безымянных branch-ей, нету…
базовое и неотъемлемое свойство branch-а — это его имя·
та последовательность коммитов, что не имеет у своей верхушки имени (верхушка ни branch-ем не является, ни tag-ом не помечена) — это просто мусор·

[sash-kan]

повторяю - как оно задумывалось, и как это всё реализовано физически - меня волнует слабо. В этом плюс hg - нет нужды знать, как это всё хранится/работает.

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

[watashiwa_daredeska]

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

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

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

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

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

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

запускает релиз в продакшен

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

Естественно удобно, если тимлидер работает за компьютером, который 24/7 в Сети, и в который можно в любой момент запушить изменения.

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

ну нету в git безымянных branch-ей, нету…

С т.з. mercurial, только они и есть :)

[sash-kan]

или скажем компьютер доступный по ssh, или в простейшем случае другой каталог, или компьютер доступный по http (достаточно выполнить hg serve, и компьютер превращается в hg-сервер, правда ReadOnly, зато с web интерфейсом. Вот с таким). Разницы между репозиториями никакой нет - все одинаковые, не смотря на свою физическую реализацию.

вы так говорите, как будто что-то из перечисленного — нечто уникальное·
огорчу вас — в git репозиторий тоже может быть доступен как локальный каталог и как удалённый каталог, доступный по ssh·
и даже по http можно репозиторий расшарить, и даже по протоколу git, и даже в связке git+ssh·
и как у нормальной dvcs, у git-а нет «центрального» репозитория·
всё это, я надеюсь, вы и сами знаете, но тогда непонятно, для чего написано процитированное…

[drBatty]

Ну, я как-то практикую другую схему:
1. Изменение.
2. Синхронизация. Делится на:
2a. fetch
2b. merge
Делать fetch, потом изменять, а потом делать слияние — для меня что-то довольно странное.

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

Но после pull изменений в этой ветке — уже не соответствует ни Вашему каталогу в момент Вашего коммита, ни каталогу в его текущем состоянии. А значит, с моей т.з., не соответствует им вообще.

после pull в этой ветке, tip соответствует рабочему каталогу того кодера, который сделал последний push в эту ветку.
либо, если я сделал pull прямо из репозитория этого кодера, то tip соответствует его каталогу, в момент его последнего коммита, если конечно он сделал этот последний коммит, а не я. Всё логично - мы работаем с одним и тем-же каталогом, и после pull ревизия tip указывает на последний коммит, вне зависимости от того, кто его сделал.

tip в hg тоже соответствует тому состоянию рабочего каталога, от которого отслеживаются изменения. Тоже - всегда.

Не всегда. Если после pull перемещается tip, затем я делаю изменения в каталоге и hg commit, то появится новый head, не от tip, в котором не будет изменений, которые были в tip.

да. второй tip от первого tip'а отслеживается, но третий tip будет отслеживаться тоже от первого, ибо вы не изменили состояние рабочего каталога на второй tip, и потому у вас вырастает голова из старого первого tip'а. Я не очень понимаю, что тут нелогичного?
вася свернул налево и ушёл. Если посмотреть, кто куда ушёл, то очевидно вася куда-то ушёл. А петя не пошёл за васей, а свернул направо. Очевидно, раз петя не пошёл за васей, то его перемещение отслеживается из исходной точки, а вовсе не от васи. Что тут нелогичного?
С точки зрения _логики_ всё как раз очень логично. Хотя может быть и сложно, если мыслить как в однозадачных и однопользовательских ОС.
Мыслите шире - проект в Вашем вашем каталоге - это вовсе не единственный путь: где-то есть другие каталоги, файлы в которых могут иметь иное содержание. А DVCS просто отображает, отслеживает, и сохраняет ВСЕ изменения во ВСЕХ проектах и каталогах одновременно. Не удивительно, что если каталог один, то он может иметь несколько состояний на разных компьютерах - это и есть ветвление в hg. Да, один и тот-же файл, в одном и том же проекте, в одно и тоже время имеет разное содержимое. Ну и что тут такого?

[watashiwa_daredeska]

естественно, для полноценной работы с git-ом эти знания не требуются·

Ну смотря что считать полноценной работой :)
Как по мне, git устроен очень юниксвейно. В юниксе для полноценной работы желательно знать основы: ФС, процессы, пайпы, их взаимодействие и некоторый базовый набор команд для управления ими. Точно так же, для полноценной работы в git'е, желательно представлять основные сущности, на которых всё строится, и как они взаимодействуют. Так сказать, от простого к полезному.
Помогает тут именно простота основ, как и в случае юниксов. В случае же hg всё начинается сразу с довольно сложных сущностей с нетривиальным поведением.