oscript-library
oscript-library copied to clipboard
EvilBeaver
gitsync: Обрабатывать только одну версию хранилища 1С за один запуск, а не все новые версии из хранилища 1С
gitsync: Обрабатывать только одну версию хранилища 1С за один запуск, а не все новые версии из хранилища 1С
Например, при работе с билд-сервером нельзя управлять процессом обработки хранилища 1С.
И в случае активной разработки несколькими разработчиками обработка хранилища может идти очень долго. Особенно это критично в случае использования схемы обработки нескольких репозитариев.
А если при одном запуске обрабатывается только одна версия, появилась бы возможность прогнозирования времени работы и повысилась управляемость.
Было бы удобно добавить специальный ключ командной строки для управления.
Буквально сегодня по что-то такое думал. Да, это полезно, в т.ч. для параллельных синхронизаций по разным репам
-----Исходное сообщение----- От: "Artur Ayukhanov" [email protected] Отправлено: 19.10.2015 20:05 Кому: "EvilBeaver/oscript-library" [email protected] Копия: "Andrei Ovsiankin" [email protected] Тема: Re: [oscript-library] gitsync: Обрабатывать только одну версию хранилища 1С за один запуск, а не все новые версии из хранилища 1С (#19)
@EvilBeaver что скажешь? — Reply to this email directly or view it on GitHub.
для параллельных синхронизаций по разным репам
Вопрос: как в случае использования конфигурации с несколькими репозитариями и возможным параллельным запуском запретить параллельно запускать билды для одного репозитария?
Без положительного ответа на этот вопрос нельзя реализовать текущую задачу для конфигураций с несколькими репозитариями.
ИМХО никак не запретить, т.к. никак не отследишь параллельный запуск :( если только где-то фиксировать состояние, например, в файле. но в случае работы через агентов на билд-сервере это не имеет смысла.
Для варианта конфигурации с одним репозитарием реализовать можно.
@artbear способ, в принципе, общепринятый - lock-файл, определяющий доступ к разделяемому ресурсу.
способ, в принципе, общепринятый - lock-файл, определяющий доступ к разделяемому ресурсу.
@EvilBeaver я уже выше писал
ИМХО никак не запретить, т.к. никак не отследишь параллельный запуск :( если только где-то фиксировать состояние, например, в файле. но в случае работы через агентов на билд-сервере это не имеет смысла.
ИМХО в случае агентов на разных машинах это довольно сложно обеспечить :(
После pull надо смотреть, если мы собираемся распаковать версию, а в файле VERSION она уже распакована, значит, кто-то нас опередил с другой машины. Надо прописать вообще, зачем нам как-то это запрещать и чем нам грозит параллельная синхронизация по одной и той же репе. Когда будут прописаны риски, тогда можно посмотреть, чем то или иное плохо и выработать поведение в каждой из ситуаций.
После pull надо смотреть, если мы собираемся распаковать версию, а в файле VERSION она уже распакована, значит, кто-то нас опередил с другой машины
+1
Чем нам грозит параллельная синхронизация по одной и той же репе
Навскидку: -риск путаницы в порядке коммитов, -могут быть расхождения с порядком из хранилища 1С, -двойное помещение одного коммита из хранилища 1С в Гит (интересно, как Гит разрулит эту ситуацию)
по идее git будет ругаться на конфликт в файле version и не даст сделать push
@EvilBeaver какой конфликт-то? мы же делаем пулл и просто штатно меняем этот файл. Для Гит это обычное изменение файла
@artbear пулл и изменения-то он даст сделать. А при пуше на remote уже выдаст ошибку с требованием повторного пулла
@nixel2007 Да, согласен, пуш не пройдет. Тогда все, больше рисков не вижу.
@pumbaEO а ты что думаешь по этой теме?
имхо отдельный параметр запуска сколько версий делать синхронизацию, по умолчанию бесконечно, если указали 1 тогда будет одна версия синхронизированна.
@pumbaEO какие проблемы/риски при параллельной работе двух синхронизаций одного репозитария возможны?