понедельник, 6 сентября 2010 г.

Ветвления в бранче

Все-таки это зло.

Mercurial позволяет двум разработчикам независимо сделать push, что приведет к тому что в бранче на сервере получится ветвление. Но что делать третьему разработчику, который это вытягивает? Заниматься слиянием? Да он вообще не в курсе что там куда.

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

Должна быть в системе контроля версий какая-то однозначность. Мне кажется логичным, что тот, кто первый закоммитил - тот и продолжил бранч. А отставшие должны приложить усилия (сделать rebase) чтобы вернуться в бранч.

Про git - я тащусь... цитирую: "Чтобы на самом деле разобраться в способе ветвления в Git, мы должны сделать шаг назад и рассмотреть, как Git хранит свои данные". А как же абстракция, сокрытие реализации и тд?

Долго курил маны, так и не понял. Если в ветку удаленного репозитория git кто-то пропихнул свои изменения, git откажет мне в push?

В принципе в git все сделано грамотно, только слишком уж низкоуровнево.

4 коммент.:

Анонимный комментирует...

Да, git откажет в пуше. Можно сделать так, чтобы он разрешил пушить и перетирать ref'ы - для этого надо _на_сервере_ включить опцию allow non-fast-forward push.

>А как же абстракция, сокрытие реализации и тд?

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

Andrey Valyaev комментирует...

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

Я бы предпочел чтобы можно было использовать разные хранилища... Google наверное потому и заюзал Mercurial, что его можно было привязать к BigTable.. А вот git не смогли...

Везде свои плюсы и минусы...

afunix комментирует...

Да. Git откажет в push и заставит сделать pull. Затем исправить конфликты, которые он сам не может разрешить. После этого можно сделать push.

Если в mercurial не так, то, пожалуй, я его никогда не буду использовать...

Andrey Valyaev комментирует...

Ну зачем же так категорично?

Я лично не вижу ничего плохого в ветвлениях на сервере.

Просто странно, что hg считает все ветви принадлежащими одному бранчу. Это нарушает линейность истории.

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

Что совершенно не лишает пользователей возможности сделать мердж позже.

Или например мерджеванием мог бы заниматься специальный Линус Торвальд... :) А все чужие пуши по определению мимо ветки.

Стратегий может быть много разных.