Я работаю над проектом разработки программного обеспечения, который требует, чтобы я работал в двух разных хранилищах SVN. Первым репозиторием является клиентский репозиторий, а второй репозиторий - это наш внутренний репозиторий. Я пытаюсь найти наиболее эффективный способ управления развитием между двумя репозиториями.Управление разработкой между несколькими хранилищами SVN
Немного больше информации о настройке ...
Репозиторий клиент является хозяином. Несколько продавцов параллельно работают над развитием в отдельных филиалах. Когда ветка завершена, она реинтегрируется в багажник, и все активные ветви сливаются с багажником. У меня может быть 2-3 активных филиала в клиентском репозитории в данный момент времени.
Мое хранилище для разработки - это место, где происходит развитие всей моей команды. Мы не используем репозиторий клиентов исключительно из-за отсутствия интеграции с нашими инструментами разработки для обзора кода и управления задачами. Когда проект начинается, мы экспортируем источник из ветки в клиентский репозиторий и импортируем его в наш репозиторий. Вот где мой вопрос приходит ...
Каков наилучший способ управления развитием между двумя хранилищами для данной ветки? В течение жизни проекта могут быть обновления для нашего филиала в клиентском репозитории, которые необходимо загрузить в наш репозиторий. Мы также должны иметь возможность отправлять изменения в наш филиал в репозитории клиентов для выпусков.
Я придумал два возможных вариантов к настоящему времени:
использовать патчи для управления изменениями между ветвями. Падение здесь - это любые изменения древовидной структуры, которые не будут включены.
Используйте svnrdump, чтобы воспроизвести изменения между ветвями. Проблема с этим подходом заключается в том, что я не уверен, что цель этого инструмента и что произойдет, если пересмотренная версия будет противоречить изменениям, которые мы сделали. Инструмент предназначен в первую очередь для переноса репозиториев.
SVN 1.7 используется для обоих серверов.
Любые мысли или предложения приветствуются.
Откровенно говоря, это случай, когда Subversion просто не имеет хорошего рабочего процесса. –