LINUX.ORG.RU

[Mercurial][subrepo] hg push без экстерналов


0

2

В общем, пользуюсь bitbucket-ом, в нем есть subrepo, когда делаю push, разумеется коммит и в субрепозиторий. Но есть проблема: когда субрепозиторий вообще никак не затронут и не изменен, то при push оно все равно пушает в него.

Вопрос: что если у меня нет доступа на сервер где лежит субрепозиторий, что если я там вообще ветку создал, которую опять же нельзя туда совать - как мне отучить Mercurial пушить в субрепозитории, есть ли ключики для этого?

>то если у меня нет доступа на сервер где лежит субрепозиторий, что если я там вообще ветку создал, которую опять же нельзя туда совать - как мне отучить Mercurial пушить в субрепозитории, есть ли ключики для этого?

ИМХО никак. Это [хочется странного]

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

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

I-Love-Microsoft ★★★★★ ()

Да говно кривое этот subrepo :(. Есть альтернативные поделия. Но, боюсь, примерно той же кривизны.

Я бы забомбил нормальный нормальный(ну или subrepo допилил чтобы он сохранял бОльше информации в .hgsubstate чтобы потом было понятно что push-ить), но 1) нет времени 2) в прошлый раз уже натрахался с написанием плагина для hg(чтобы hg status работал с subrepo), больше желания связываться с его кишками нет.

true_admin ★★★★★ ()
Ответ на: комментарий от I-Love-Microsoft

>ну почему же странного - есть внешний реп, у меня нет доступа на него, а я с ним работаю - и чо я буду пушить в него если он рид онли???

погодите, я чего-то видимо не понимаю - у вас что, hg САМ ПО СЕБЕ пушит? У меня только по команде push, а по команде pull или clone ничего не пушит. Ну если у меня права РО, зачем мне пушить?

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

> Да говно кривое этот subrepo :(

+1, не очень юзабельно пока получается, лучше бы сделали нормальный аналог git subtree

kamre ★★★ ()
Ответ на: комментарий от I-Love-Microsoft

там вся идея с .hgsub/.hgsubstate изначально какая-то бредовая, т.к. нельзя работать с рерозиторием и всеми его подрепозиториями как с одним целым, еще куча сценариев не работает или работает совсем не так как надо

нужна возможность прозрачно уметь синхронизировать поддерево из одного репозитория с поддеревом другого репозитория, заодно при этом поддерживать subtree clone

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

Не юзаю и никому не советую.

Альтернатив нету :(.

Вчера впервые с svn работал в комманде. Да, svn говно, но возможность зачекаутить любую папку очень сильно выручила т.к. 1) целиком репозиторий не клонировался из-за глюков на моей стороне 2) мне нужен был только маленький кусочек, тянуть сотни метров не пришлось.

true_admin ★★★★★ ()
Ответ на: комментарий от I-Love-Microsoft

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

как только сделаешь commit в .hgsubstate утеряется старая инфа и будет непонятно какие репы синкнуты а какие нет.

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

> лучше бы сделали нормальный аналог git subtree

А что делает git-subtree, если коммит затрагивает и то самое subtree, и файлы, которые в него не входят?

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

Я читал это, но не понял, как именно оно отслеживает историю. Особенно в присуствие --squash

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

git subtree will simply leave out the non-library-related parts of the commit when it splits it out into the subproject later

Т.е. тоже самое, что и hg convert делает при выделении subtree в отдельный репозиторий.

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

Ну а метаинформацию (список коммитов, перенесенных в вдругой репозитторий или взятых из другого репозитория) он где хранит?

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

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

скорее досадная недоработка чем фундаментальный недостаток hg

I-Love-Microsoft ★★★★★ ()
Ответ на: комментарий от I-Love-Microsoft

А как он поймёт какие репозитории поменялись а какие нет? Он в .hgsubstate не хранит историю, он хранит только последнее состояние.

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

Когда делается push для parent repo, то нужно только те ревизии из subrepos проталкивать, которые есть в .hgsubstate (и всех их предков). А сейчас просто по тупому делается push для всего subrepo сразу без всякого учета .hgsubstate.

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

Ну а метаинформацию (список коммитов, перенесенных в вдругой репозитторий или взятых из другого репозитория) он где хранит?

Без понятния, т.к. не пользуюсь git. Если там есть squash, то такую метаинформацию точно нужно где-то хранить. А без него вроде ничего дополнительно не хранить, нужно только автоматически уметь сопоставлять ревизии из всего repo и те ревизии, которые получаются при сужении на subtree.

kamre ★★★ ()

А вообще есть здесь живые пользователи git-subtree? Ж)

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

нужно только те ревизии из subrepos проталкивать, которые есть в .hgsubstate (и всех их предков).

там tip-ы всех репозиториев.

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

А subrepos по своей задумке на это не расчитан и может после такого дать дуба с концами.

Его суть в том что все репозитории синхронизируются. Т.е. это не просто тупой скрипт который по папкам ходит и делает hg push, оно фиксирует состояние всех subrepos сразу. Хотя эта фича бывает очень вредна и ограничивает применение этого модуля.

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

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

I-Love-Microsoft ★★★★★ ()
Ответ на: комментарий от true_admin

А subrepos по своей задумке на это не расчитан и может после такого дать дуба с концами

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

это не просто тупой скрипт который по папкам ходит и делает hg push

Сейчас местами именно так криво и работает.

оно фиксирует состояние всех subrepos сразу

Тут возникает вопрос: а когда именно нужно это состояние всех subrepos фиксировать? Поэтому управлять историей parent repo становится не тривиально из-за этой гибкости subrepos и кучи недоделок.

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