Меркуриал

[metaclass]

В сабжевой DVCS все хорошо, но есть один слабо понятный мне момент. А именно, merge. Если ребе belnetmon сделает push в центральный репозиторий и я после этого хочу сделать тоже push, то даже если у нас никак не пересекающиеся изменения - оно этого сделать не даст, нужно сначала сделать hg pull, потом hg merge, потом hg commit и только после этого получится сделать hg push.
Может, я чего не так делаю?

Comments

[berezovsky.livejournal.com]

переходите на Microsoft Visual SourceSafe

[aamonster.livejournal.com]

hg push -f, и пусть мержит кто-то другой =).

[metaclass.livejournal.com]

Две heads в головной репе тогда появлятся?

[theiced.livejournal.com]

есть такая чтука как автомерж. а автоматом эти дейстивя проделает.

[aamonster.livejournal.com]

А так - смержить-то можно только локально (иначе кто проконтролирует корректность?), так что без pull не обойтись.

Варианты:
hg fetch - разом сделает pull-merge-push (если не возникнет конфликтов)
hg pull --rebase - сделает pull и воткнёт твои изменения после него (получится примерно как при работе с SVN - линейная история)

[aamonster.livejournal.com]

Ага, ниже написал, как без этого.

[metaclass.livejournal.com]

fetch это случаем не расширение какое нибудь?

[blacklion.livejournal.com]

Всё так делаешь. Это издержки changset-based VCS (в противовес snapshot-based, таких как CVS и subverson).

[vp.livejournal.com]

но согласись, что это какие-то издержки меркуриала? Логики ведь за этим никакой нет.

[graynm.livejournal.com]

Вообще говоря - расширение, но оно сейчас идёт в базовом комплекте.

[theiced.livejournal.com]

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

[blacklion.livejournal.com]

Есть за этим логика. У git та же фигня и у любой changset-based VCS тоже самое. Это издержки того, что мы храним именно изменения группированные, а не состояния (снепшоты).
И, да, это как раз сильно упрощает merge, хотя и делает его обязательным.

[kong-en-ge.livejournal.com]

за что вы так ненавидите этих двух трудоголиков?! :)

[alll]

А в случае конфликта двух коммитов что с этим --rebase произойдёт?

[morozov.livejournal.com]

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

[theiced.livejournal.com]

каменный век уже пару лет как кончился.

[antilamer.livejournal.com]

Пожалуется и попросит зарезолвить вручную.

[blacklion.livejournal.com]

После этих и СVS полюбишь...

[dmitry-vk.livejournal.com]

Хм, а мне казалось, что основная фича Git'а и Hg в том, что они как раз хранят снэпшоты, а не изменения.

[blacklion.livejournal.com]

Они хранят последовательность изменений (changesets).

[aamonster.livejournal.com]

Честно говоря, не пробовал, работаю по старинке - pull-merge-push (благо, merge на порядок удобнее, чем в subversion). Принцип: создавать новые ветки могут все, а вливать их в основную должен кто-то один. Хотя, конечно, для текущей работы это overkill.

Но навскидку - должно или создать файл для разрешения конфликтов, или запустить утилиту для их разрешения, прописанную в конфиге (kdiff3, к примеру).

[aamonster.livejournal.com]

Но ведь ещё пахнет, пахнет! Сегодня чекинил код.

[aamonster.livejournal.com]

У hg есть такой изврат - встроенные расширения. Они в основном коде, но для использования их надо разрешать в конфиге.
Для винды - в Mercurial.rc, секция extensions, раскомментить/вписать строки
fetch =
graphlog =
mq =
rebase =
ну и прочие по вкусу

[aamonster.livejournal.com]

На самом деле SS приводит меня в восхищение. С такой убойной архитектурой, с доступом на запись для всех клиентов - и годами работает!
Работа svn (через апач или svnserve) или тем более mercurial - естественна. Работа SS - чудо. Да, он древнее, чем говно мамонта, и так же устарел - но сделан на совесть.

[zamotivator.livejournal.com]

Нет, он такое запрещает (ругнётся ошибкой)

[zamotivator.livejournal.com]

Эти две действительно ад.
Но subversion тоже не торт.

[zamotivator.livejournal.com]

Эти две VSC умерли, и давно.

[zamotivator.livejournal.com]

TFS вообще мертворождённая.
Этим пиздецом пользоваться просто невозможно.

[gds.livejournal.com]

"-f" как раз для того, чтобы сказать "ребяты, вот вам ещё одна голова, и делайте с ней что хотите". ругаться будет, но ненавязчиво.

[theiced.livejournal.com]

subversion тоже умер. ага.

[max630.livejournal.com]

а в svn разве не надо делать update перед commit? вот тут то же самое

(disclaimer: дальше про git, возможно в hg что-то не так)

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

Следующий шаг - вообще выкинуть центральный репозиторий и расшарить свои рабочие.

Где-то было эпическое видео Линуса, где в свойственной ему манере (What do you use here? Perforce? I'm ... I'm sorry) он подробно рассказывает, как они работают с git.

[max630.livejournal.com]

скажем так, это просто нечто другое чем git/hg, со своими минусами, против их минусов, тоже не маленьких

[dmzlj.livejournal.com]

вы случайно не бранч хотите там сделать?

[dmzlj.livejournal.com]

эти три VSC