Re: [devel] Gear и внешние VCS.

[Igor Vlasenko <vlasenko@imath.kiev.ua>]

On Thu, Jun 19, 2014 at 03:10:55PM +0400, Anton Farygin wrote:
> On 19.06.2014 15:08, Igor Vlasenko wrote:
> >Соответственно, когда такие утилиты будут готовы,
> >надо будет просить всех майнтайнеров, использующих
> >VCS - обновляемые gear репозитории, создать и опубликовать
> >в этих репозиториях .gear/upstream/remotes,
> >а если есть желание ограничить доступ к своему репозиторию,
> >то делать это с помощью acl, а не сокрытием его служебной
> >информации.
> 
> я в соседнем письме написал, почему нет смысла использовать для
> этого .gear/upstream/remotes
> т.е. - я не хотел бы использовать инструмент, который будет мне
> предоставлять алгоритм работы другого ментейнра.
> например, мне привычнее upstream remote держать в бранче не
> upstream, а source.
> 
> Как тут быть ?

Легко :)

2 файла .gear/upstream/tag-filter и
.gear/upstream/remotes - это формат,
в котором будет храниться служебная информация,
которая будет необходима для watch по tag.

При этом .gear/upstream/remotes имеет более
глубокий смысл - 

* он позволяет сделать информацию о remotes публичной, 
* может использоваться независимо от того, нужен ли watch по tag, 
* крайне нужен NMUшникам.

Но из этого совершенно не следует, что если пакет foo
одновременно сопровождает 2 майнтайнера A и B, то
если один из них создал .gear/upstream/remotes,
(например, А), то второй (В) 
отгребет из этого файла не нужные ему ветви.

Ведь никто не заставляет выполнять у себя 
gear-restore-remotes, и робот тоже не будет этого
делать. Я в позапрошлом письме рассматривал алгоритм
обновления. Если в gear/rules тег, как в 
tar:v@version@: .
то там достаточно использовать временную служебную ветвь,
какой-нибудь gearobersturmbannbranch.
Однако, служебная ветвь -- это мусор в репозитории,
поэтому умный робот проверит, есть ли в .git/config
ветви, описанные в .gear/upstream/remotes,
если есть, будет использовать их, чтобы не мусорить,
если же нет, создаст свой gearobersturmbannbranch.

Если майнтайнер B тоже не хочет, чтобы у него создавался
gearobersturmbannbranch, а использовались его собственные,
отличные от майнтайнера A названия ветвей, 
он может добавить файл .gear/upstream/remotes.$USER, 
который будет иметь приоритет перед .gear/upstream/remotes.
А еще можно export GEAR_UPSTREAM_REMOTES_SUFFIX=..smth..,
и перекрыть все с помощью
.gear/upstream/remotes.$GEAR_UPSTREAM_REMOTES_SUFFIX
если вдруг понадобится.

Конечно, в gear/rules архив может создаваться не по тегу,
а по ветви: tar:upstream: .
но тогда от создания у себя ветви upstream никуда не деться,
против лома нет приема, она железобетонно прописана в gear/rules, 
разве что форкать свои .gear/rules.

Так хорошо?


-- 

I V