LINUX.ORG.RU

hg branches : непонятности!!


0

0

есть репозиторий mercurial для постоянно развивающегося проекта "project". Обновления коммитятся в branch с именем "trunk". Заказчик попросил сделать несколько специфичных изменений в исходниках, которые не нужны в основной ветке, однако заинтересован, чтобы все последующие обновления из trunk были ему доступны. Было принято решение для версии проекта заказчика сделать отдельный бранч "customer". Таким образом теперь в проекте два head:

$ hg heads
changeset: 2197...
branch: trunk -- рабочая версия.
...
changeset: 2188...
branch: customer -- версия заказчика.

теперь для синхронизации версии заказчика с trunk можно периодичести набирать:
$ hg update customer
$ hg merge -r trunk
$ hg commit

однако наоборот -- из customer в trunk -- мержить нельзя ни при каких обстоятельствах. как-то можно обезопасить репозиторий от возможности такого действия со стороны несознательного разработчика? хук какой-нить в .hgrc?

или есть лучшие способы для работы с версиями проектов?

★★

Во-первых, говоря о бранчах в Mercurial, всегда нужно указывать версию Mercurial (там перед самым 1.0 переколбасили поддержку бранчей); ао-вторых, большинство спецов по Mercurial и сейчас рекомендуют модель branch-per-repository. ИМХО, это как раз то, что вам следует сделать - отдельный репозиторий customer (и в нем просто не прописывать default-push в hgrc).

> хук какой-нить

Можно и так - повесить на хук pretxnchangegroup в вашем основном репозитории проверку прихода, например, первого changeset из customer. Если он обнаружен во входящей changegroup, сообщать об этом и откатывать транзакцию.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

> А что изменилось?

Всё стало еще лучше %) Точно не знаю, ибо олдскул и придерживаюсь branch-is-a-repo.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> версию Mercurial

Mercurial Distributed SCM (version 1.0.1)

> отдельный репозиторий customer

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

> pretxnchangegroup в вашем основном репозитории проверку прихода, например, первого changeset из customer. Если он обнаружен во входящей changegroup, сообщать об этом и откатывать транзакцию

подскажите, где про это можно почитать, или готовую строчку для .hgrc, если не затруднит.

Lucky ★★
() автор топика
Ответ на: комментарий от Lucky

> подскажите, где про это можно почитать

Mercurial Book, вестимо. Там есть глава о хуках, ну и вообще полезно. http://hgbook.red-bean.com

> или готовую строчку для .hgrc

[hooks]
pretxnchangegroup.blacklist = ../bl

Заметь, что скрипты ищутся (и запускаются) в корне репозитория, но данная
реализация bl лежит вне репозитория, поэтому "../". Чтобы два раза 
не вставать, вот сама проверка (запрещенные хэши хранятся в файле 
blacklist рядом с bl):

echo "Я злой страшный blacklist hook >8-E"

stars="************************************************************************
********"
n=0

for i in $(sed 's/#.*//' < ../blacklist); do
        if hg log -q -r $i 2>/dev/null >/dev/null; then
                [ $n -eq 0 ] && echo -e "$stars\nОбнаружены изменения, занесенные в \"черный список\"!\n"
                hg log -r $i
                n=$[$n + 1]
        fi
done

if [ $n -gt 0 ]; then
        echo "-------------------"
        echo "В добавляемых изменениях обнаружено $n изменения из \"черного списка\"."
        echo "Попытайтесь добавить только нужные изменения ('hg push -r')."
        echo "$stars"
        exit 1
fi

echo "...ладно, на этот раз ты проскочил :D"
exit 0

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Mercurial Book, вестимо.

tnx. читаю. нашел мутное описание похожей ситуации в http://hgbook.red-bean.com/hgbookch8.html#x12-1660008.8

воткнул, по аналогии:

[hooks] pretxnchangegroup.branch = hg heads --template '{branches} ' | grep trunk | grep customer

в надежде, что это сохранит оба head. не понимаю, правильно-ли.

> запрещенные хэши хранятся в файле blacklist рядом

а что такое запрещённые хеши? где взять? как это решает проблему merge "customer" в "trunk"?

Lucky ★★
() автор топика
Ответ на: комментарий от Lucky

> не понимаю, правильно-ли.

Мне кажется, что неправильно.

> а что такое запрещённые хеши?

хэши changeset'ов, которые не должны проникнуть в этот репозиторий.

> где взять?

hg log их показывает (длинное хексовое число после локально номера ревизии)

> как это решает проблему merge "customer" в "trunk"?

_Это_ не решает проблему merge "customer" в "trunk" (если ее и решать, то precommit-хуком, но там свои грабли), это решает проблему попадания изменений из "customer" в репозиторий, в котором вообще не должно быть "customer".

Это всё рассчитано на использование модели "repo-is-a-branch". Если тебе обязательно хранить в одном репозитории 2 бранча, то сделай precommit-хук, который проверяет (черезе hg parents), что merge прошел в правильном направлении. Проверка, в общем-то, бессмысленная, но ты можешь ее сделать.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

ок, раз столько сложностей, то идея с бранчами неверна. поднял второй репозитарий. tnx за помощь.

Lucky ★★
() автор топика
Ответ на: комментарий от Lucky

> ок, раз столько сложностей

Говорят, бранчи в Mercurial нисколько не сложны :) Просто я лично их не использую, потому как "repo-is-a-branch" - еще проще (если нет завязок на Trac или что-то похожее, но в Trac идет работа над поддержкой нескольких репозиториев на проект).

tailgunner ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.