gitsync: Обрабатывать только одну версию хранилища 1С за один запуск, а не все новые версии из хранилища 1С

[artbear]

gitsync: Обрабатывать только одну версию хранилища 1С за один запуск, а не все новые версии из хранилища 1С

Например, при работе с билд-сервером нельзя управлять процессом обработки хранилища 1С.

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

А если при одном запуске обрабатывается только одна версия, появилась бы возможность прогнозирования времени работы и повысилась управляемость.

Было бы удобно добавить специальный ключ командной строки для управления.

[artbear]

@EvilBeaver что скажешь?

[EvilBeaver]

Буквально сегодня по что-то такое думал. Да, это полезно, в т.ч. для параллельных синхронизаций по разным репам

-----Исходное сообщение-----
От: "Artur Ayukhanov" notifications@github.com
Отправлено: ‎19.‎10.‎2015 20:05
Кому: "EvilBeaver/oscript-library" oscript-library@noreply.github.com
Копия: "Andrei Ovsiankin" ovsiankin.aa@gmail.com
Тема: Re: [oscript-library] gitsync: Обрабатывать только одну версию хранилища 1С за один запуск, а не все новые версии из хранилища 1С (#19)

@EvilBeaver что скажешь?
—
Reply to this email directly or view it on GitHub.

[artbear]

для параллельных синхронизаций по разным репам

Вопрос: как в случае использования конфигурации с несколькими репозитариями и возможным параллельным запуском запретить параллельно запускать билды для одного репозитария?

Без положительного ответа на этот вопрос нельзя реализовать текущую задачу для конфигураций с несколькими репозитариями.

ИМХО никак не запретить, т.к. никак не отследишь параллельный запуск :( если только где-то фиксировать состояние, например, в файле.
но в случае работы через агентов на билд-сервере это не имеет смысла.

Для варианта конфигурации с одним репозитарием реализовать можно.

[EvilBeaver]

@artbear способ, в принципе, общепринятый - lock-файл, определяющий доступ к разделяемому ресурсу.

[artbear]

способ, в принципе, общепринятый - lock-файл, определяющий доступ к разделяемому ресурсу.

@EvilBeaver я уже выше писал

ИМХО никак не запретить, т.к. никак не отследишь параллельный запуск :( если только где-то фиксировать состояние, например, в файле.
но в случае работы через агентов на билд-сервере это не имеет смысла.

ИМХО в случае агентов на разных машинах это довольно сложно обеспечить :(

[EvilBeaver]

После pull надо смотреть, если мы собираемся распаковать версию, а в файле VERSION она уже распакована, значит, кто-то нас опередил с другой машины. Надо прописать вообще, зачем нам как-то это запрещать и чем нам грозит параллельная синхронизация по одной и той же репе. Когда будут прописаны риски, тогда можно посмотреть, чем то или иное плохо и выработать поведение в каждой из ситуаций.

[artbear]

После pull надо смотреть, если мы собираемся распаковать версию, а в файле VERSION она уже распакована, значит, кто-то нас опередил с другой машины

+1

Чем нам грозит параллельная синхронизация по одной и той же репе

Навскидку:
-риск путаницы в порядке коммитов,
-могут быть расхождения с порядком из хранилища 1С,
-двойное помещение одного коммита из хранилища 1С в Гит (интересно, как Гит разрулит эту ситуацию)

[EvilBeaver]

по идее git будет ругаться на конфликт в файле version и не даст сделать push

[artbear]

@EvilBeaver какой конфликт-то? мы же делаем пулл и просто штатно меняем этот файл.
Для Гит это обычное изменение файла

[nixel2007]

@artbear пулл и изменения-то он даст сделать. А при пуше на remote уже выдаст ошибку с требованием повторного пулла

[artbear]

@nixel2007 Да, согласен, пуш не пройдет.
Тогда все, больше рисков не вижу.

@pumbaEO а ты что думаешь по этой теме?

[pumbaEO]

имхо отдельный параметр запуска сколько версий делать синхронизацию, по умолчанию бесконечно, если указали 1 тогда будет одна версия синхронизированна.

[artbear]

@pumbaEO какие проблемы/риски при параллельной работе двух синхронизаций одного репозитария возможны?