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

[Anton Farygin]

On 19.06.2014 15:55, Igor Vlasenko wrote:
> 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.

Умный робот мог бы посмотреть, если ли remotes на апстрим, описанный в 
watch файле и если есть - сделать fetch им, а не в отдельную служебную 
ветку.

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

а что делать, если мейнтейнер не хочет записывать что-то в 
.gear/upstream (и тем более публиковать это) ?

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

Нет, плохо.

Мне хотелось бы понять, чем не устраивает вариант с созданием веток под 
"настройки мейнтейнера" а не в соответствии с .gear/upstream/remotes ?

Зачем плодить лишние сущности ?

сделайте в домашнем каталоге .uupdate-branches и в нём пропишите все 
необходимые ветки.

ну и дефолт в виде upstream upstream