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

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

На примере netxms расскажу планы по автоматизации работы 
с VCS - обновляемыми gear репозиториями.

Итак, если у нас один VCS - обновляемый gear репозиторий,
то проверить, есть ли обновление, тривиально. заходим,
запускаем git fetch <upstream>, глазами смотрим, что приехало.

Если же у нас 100 gear репозиториев, то, тратя по 20 секунд
на репозиторий, их ручная проверка заберет у нас больше, чем пол часа.

Хотелось бы в духе unix-way напустить на нашу коллекцию
gear репозиториев какой-нибудь умный скрипт, скажем,
будущий rpm-uscan, который меньше чем за минуту
проверил бы все репозитории, съэкономив бы нам полчаса,
и даже эту минуту, пока он работал, можно было бы потратить с пользой,
сделав новую чашку кофе.

С tarball обновляемыми gear репозиториями справляется 
и старый rpm-uscan, осталось научиться работать 
с VCS - обновляемыми gear репозиториями.
Там тоже простой алгоритм - руками мы 
запускаем git fetch <upstream>, глазами смотрим, что приехало.

Просмотр робот будет делать так: запускает git tags, фильтрует
(по умолчанию будет фильтр ^ v?([0-9\.]+[0-9]) $,
если апстрим любит теги в другом формате, к примеру,
1.2-release, то для них надо будет создать специальный
файл, скажем, .gear/upstream/tag-filter, формат и опции 
будут похожи на debian/watch),
сравнивает версии из отфильтрованных тегов с текущей,
и если найдет бОльшую, то приехало обновление.

но, перед просмотром, робот должен знать remote <upstream>.
просто просмотреть теги ему достаточно будет git ls-remote --tags <upstream>
а для обновления ему понадобится сделать git fetch <upstream>.

Соответственно, нужно указать роботу, какой remote использовать.
для этого нужен будет специальный файл, скажем, .gear/upstream/remotes.

Формат этого файла, думаю, формат git-config(1).
в нем должен находиться фрагмент .git/config,
который отвечает за текущие используемые remotes.

Для netxms .gear/upstream/remotes будет иметь вид:
==== .gear/upstream/remotes =========================
[remote "upstream"]
        url = git://git.netxms.org/public/netxms.git
        fetch = +refs/heads/*:refs/remotes/upstream/*
=====================================================
если бы использовался мерж в локальную ветвь upstream, 
то там могло бы быть что-то вроде
==== .gear/upstream/remotes =========================
[remote "upstream"]
        url = git://git.netxms.org/public/netxms.git
        fetch = +refs/heads/*:refs/remotes/upstream/*
 [branch "upstream"]
        remote = upstream
        merge = refs/heads/upstream
=====================================================
его можно легко создать руками, скопировав туда нужный 
кусок из .git/config.
Обратно восстановить рабочий .git/config в клоне из
неполноценной копии на git.alt тоже тривиально:
cat .gear/upstream/remotes >> .git/config.

Но, конечно, лучше иметь специализированные утилиты
gear-store-remotes / gear-restore-remotes.
так, gear-restore-remotes сделает backup .git/config,
проверит, нет ли уже там тех ключей, и не 
запустится, если найдет.

gear-store-remotes проверит сначала, есть ли .git/remotes/*.
если найдется .git/remotes/foo, не указывающий на git.alt,
gear-store-remotes посоветует сначала сконвертировать его
в новый формат (в .git/config) командой
git remote rename foo foo
и с таким сообщением завершится.
Далее, в случае .git/config для netxms внизу,
gear-store-remotes проигнорирует [remote "origin"],
так как он указывает на git.alt.
Для netxms останется 2 remote:
[svn-remote "svn"] и [remote "upstream"].
если бы остался только один,
gear-store-remotes его бы молча и выбрал,
а также, если есть, связанные с этим remotes бранчи.

Поскольку найдено 2 remote, то утилита спросит у майнтайнера, 
какие из них сохранить. можно ей указать опциями, --all-remotes, 
или --remotes=upstream, или же она выведет dialog(1)
чтобы майнтайнер отметил, какие remotes он светит наружу,
для того, чтобы другие майнтайнеры и роботы могли пользоваться
его gear репозиторием.
Затем утилита записывает выбранный фрагмент конфига
 в .gear/upstream/remotes и вызывает 
git add .gear/upstream/remotes.

Теперь репозиторий, в котором есть .gear/upstream/remotes,
становится полноценным с точки зрения возможности совместной рааботы.

Работа с ним выглядит приблизительно так:

$ girar-clone-build-commit foo
$ cd foo.git
$ gear-restore-remotes
$ gear-fetch
$ fix bugs (например, оформляем апстримный коммит с исправлением как патч)
$ srpmnmu -i *.spec
$ girar-nmu-helper-git-push-build -c -T
$ cd ..
$ rm -rf foo.git

Соответственно, когда такие утилиты будут готовы,
надо будет просить всех майнтайнеров, использующих
VCS - обновляемые gear репозитории, создать и опубликовать
в этих репозиториях .gear/upstream/remotes,
а если есть желание ограничить доступ к своему репозиторию,
то делать это с помощью acl, а не сокрытием его служебной
информации.


On Thu, Jun 19, 2014 at 12:00:08PM +0400, Eugene Prokopiev wrote:
> 19 июня 2014 г., 11:52 Igor Vlasenko написал:
> > Прошу прощения, пришлите, пожалуйста, из netxms.git еще для опытов
> > .git/config и, если есть что-то в .git/remotes/ (в старом формате),
> > то и их.
> Пожалуйста:
> 
> $ cat git/netxms/.git/config
> [core]
>         repositoryformatversion = 0
>         filemode = true
>         bare = false
>         logallrefupdates = true
> [svn-remote "svn"]
>         url = https://svn.netxms.org/public/netxms
>         fetch = trunk:refs/remotes/trunk
>         branches = branches/*:refs/remotes/*
>         tags = tags/*:refs/remotes/tags/*
> [remote "origin"]
>         url = git.alt:packages/netxms
>         fetch = +refs/heads/*:refs/remotes/origin/*
> [branch "master"]
>         remote = origin
>         merge = refs/heads/master
> [remote "upstream"]
>         url = git://git.netxms.org/public/netxms.git
>         fetch = +refs/heads/*:refs/remotes/upstream/*
> 
> $ ls git/netxms/.git/remotes
> ls: невозможно получить доступ к git/netxms/.git/remotes: Нет такого
> файла или каталога
> 
> Апстрим переехал с svn на git некоторое время назад

-- 

I V