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

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

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

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

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

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

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

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

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

а... понятно. Согласен. Не юзаю и никому не советую.

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

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

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

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

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

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

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

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

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

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

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

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

Тут чё-та написано по этому поводу(как минимум с 54-й строки) но я щас уже не втыкаю что происходит:

https://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt

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

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 в отдельный репозиторий.

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

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

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

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

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

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

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

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

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

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

Не обязательно, т.к. могли уже накоммитить в subrepos, а в parent repo не было коммитов.

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

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

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

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

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

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

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

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

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