Меркуриал

[metaclass]

Одной вещи в меркуриале я в принципе понять не могу.
Я меняю файл А, делаю commit и push, потом я меняю дома файл Б и делаю commit, а на попытку push меня посылают фпень делать pull/merge/commit.
Вопрос - почему бы независимые изменения в разных папках не мержить автоматом, как это сделано в svn?

PS: А теперь рассмотрим, как это положено делать:
1) дерево исходников представляет собой граф, узлы которого - каталоги и блобы с файлами, а связи - связь между каталогом и расположенными в нем подкаталогами и файлами.
2) пользователь 1 меняет файл с путем A
3) пользователь 2 меняет другой файл с путем B.
4) Друг другу они в принципе никак не мешают - структура графа не меняется, меняются два независимых узла.
5) операции коммутируют - т.е. вне зависимости от порядка применения операций, результат будет одним и тем же.
6) для коммутирующих операций merge должен делаться, очевидно, автоматически.

Comments

[kaa-mmf.livejournal.com]

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

[avnik.livejournal.com]

Я могу объяснить на пальцах -- почему гит тебя пошлет мержить. А тут -- хрен его знает. Корни проблемы те же я подозреваю

[kiryl.livejournal.com]

> PS: А теперь рассмотрим, как это положено делать:

Ты упускаешь важную часть графа. Про mercurial не скажу, в git оно выглядит так: есть четыре вида объектов: blob, tree, commit, tag. Все объекты адресуются по содержимому -- хэш от содержимого.

Что содежит blob понятно. tree -- список ссылок на blob'ы и другие деревья. Таким образом строится иерархия. commit -- ссылка на корневое дерево проекта, commit message + нуль или более ссылок на parent commit (больше 1 для merge commit). tag -- ссылка любой объект, чаще всего commit.

Из вышесказанного очевидно, что изменение одного blob'а повлечёт к изменению всех объектов выше по стеку: blob -> tree -> commit -> tag.

Т.е. операции не коммутирующие. И это сделано намеряно. Для distributed scm критически важно лёгкое отслеживание целостности, дабы избежать code injection и прочие проблемы с безопастностью.

[voidex.livejournal.com]

Не должен. Если A' + B работает, и A + B' работает, не значит, что A' + B' будет тоже работать, пусть программист об этом знает и ручается.
Смержит он сам, достаточно pull+push.

[max630.livejournal.com]

бгг

Обычно это делается так: пользователь A заводит merge request, потом пользователь B делает review изменений и заставляет A исправить ошибки. Потом специальный человек, когда у него дойдут руки (примерно раз в несколько дней), собирает эти реквесты и мержит (или ребейзит) их в мастер, при необходимости дёргая A чтобы он поправил конфликт.

А вы, ну я не знаю, смиритесь наверное. Или наколхозьте автомержилку на сервере.

[djuffin.livejournal.com]

Чтобы программист знал, что были изменения и деклорация метода который он вызвает была удален из совершенно независимого файла.

[berezovsky.livejournal.com]

Ну это ты знаешь, что они независимые. А он не знает.
Пришёл домой, сделал пул, вспомнил, что во второй папке написал херню, поправил и запушил всё сразу.
Я так понимаю.

[gds.livejournal.com]

> а на попытку push меня посылают делать pull/merge/commit.

не обязательно. hg push -f не посылает. Очень полезно в случаях, когда мержить должен не тот, кто пушит.
Кроме того, вроде где-то видел хрень (то ли настройка, то ли расширение), которое то ли команду добавляет, то ли опцию к push, вызывающую автоматический pull + merge + commit + push, или же rebase, не помню. (кстати, "hg rebase" таки существует.)

Остальное сказали.

Ну и да, merge сделается почти автоматически -- без конфликтов.

[vp.livejournal.com]

Почитал комменты и ничего не понял, что делать.

[x-den.livejournal.com]

если проблема в лишних движениях, то поможет hg fetch (FetchExtension), он pull/merge/commit делает автоматически, и если нет конфликтов, то вмешательства в это дело не требуется.

оопс, его уже выше успели предложить.

[vit-r.livejournal.com]

Друг другу они в принципе никак не мешают

Это не факт.

[zamotivator.livejournal.com]

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

Правильный подход либо mercurial - держать два head, либо git - запрещать push с outdated head

[levgem.livejournal.com]

Это нормально.

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

[dmzlj.livejournal.com]

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

[dmzlj.livejournal.com]

вы тут точно не обкурились все? есть стандартный workflow, который делает то, что нужно, и покрывает 90% случаев.

pull - update - commit - push. с любого рабочего места. всё. какие еще файлы? какая коммутация-мастурбация? вы чего тут?

[http://users.livejournal.com/_slw/]

ну так и используй svn