Хорошее замечание)

Слабоумие и отвага - как раз про нас

Я б сказал Отважные

Пока решили что попробовать мержить ветки,  чем стопить разработчиков потому что кто-то залочил объект в хранилище. Передумать вроде не сложно ;)

Если думать что решение мердж конфликта не является стопом, то конечно )

У нас планируется отдельный человек под это, поэтому не должно стопить непосредственно разработчиков

Дискотека 80-х "What is love. Baby don't hurt me. Don't hurt me no more."

Gitsync + задание по расписанию в Винде. Дженкинс наверное тоже можно прикрутить. Хотелось бы как-то перехватить событие помещения в хранилище, по событию дергать выгрузку из Дженкинс. Ну и в целом Дженкинс наверное удобнее чем батник.

Когда svn был большим а git маленьким говорят была целая должность "менеджер по merge" хотите воскресить этот теплый ламповый ужас

Все уже есть. Хранилище перевести на хттп и повесить проксю

Не занимался пока. Где-то видел про проксю, может когда-то займусь. Пока раз в 30 минут выгружаю, хватает для кодревью.

Мы все же извратились и написали тулзу на Яве по перехвату tcp  пакетов храна

Столько интересности повылезало с работой хранилища...

Ну поиграли и бросили(((

Все же синхронизация через gutsync  лучше взошла

Пытались пакет с конфигурацией распаковать?

Там выше написали, что нету хранилища. 😁

Этим человеком непременно должен быть тот, что принимает решение работать без хранилища с гитом ))

Проблема конкурентного доступа должна начинать решаться через правильное деление задач и отказ от модулей на 100.000 строк на все случаи жизни) Тогда 5-10 человек почти не ждут друг друга.

Ушел такой человек (кто распределяет или кто потом мержит) в отпуск на месяц и чего всем делать?

Распределять - просто. Сами программисты это могут сделать. Условно РП могут дать задачу двум программистам добавить два разных реквизита в один объект. Программисту виднее, как задачи могут быть сгруппированы. Если только программист не тупой джун.

А вот смержить изменения - это окажется в большинстве случаев дольше и сложнее, чем ожидание объекта в хранилище. При этом можно задачу делать расширением или в отдельной базе, а потом перенести код или объединить цф.

Вот и я про то же - делать самому себе фактор автобуса, нанимая отдельного чувачка под мерж, может выйти боком

Есть ли механизм или методика сверки результата интеграции? Формат регулируется xsd схемой, обмен xml пакетами, системы не идентичные.
Условный кейс - проверить результат перелива объекта из Система1 в Система2.

Попробовать получить той же интеграцией отправленные данные. Типа сделали post, а потом через get проверяем