Как указать единую базу кода на несколько проектов SVN

Question

Организация смотрит на переход от Visual Source Safe to Subversion. Нынешний подход в VSS использует один и тот же локальный проект Netbeans для обработки кода dev, qa и release, при этом изменения загружаются из локального проекта (например, P: \ test) в соответствующий проект VSS (например, dev). При поиске в Интернете я вижу множество ресурсов, описывающих указание SVN на общую базу кода, например. here, или here, но это, как и другие, похоже, разделяет ресурсы между несколькими проектами, вместо того, чтобы иметь единую базовую точку кода для нескольких проектов в репозитории.

Я чувствую, что было бы лучше, чтобы каждый проект локально (т.е. dev, qa и release) указывал на конкретный репозиторий и копировал файлы, которые нужно переместить из say dev в qa, вместо того, чтобы пытаться реплицировать подход VSS одного локального проекта используется для хранения нескольких базовых кодов репозитория. Любые мнения очень оценили!

Answer 1

Subversion не поддерживает копирование файлов между репозиториями вообще. Поддержание 3 репозиториев для одного и того же проекта приведет к безумию.

И вы не хотите иметь «несколько кодовых баз» - это все одна кодовая база, вам просто нужно иметь четкий процесс перемещения ваших изменений с dev на qa, чтобы освободить. Для этого вам нужна комбинация тегов &. С регулярными слияниями изменений. Точная реализация сводится к тому, как вы управляете разработкой своего приложения, и это может изменить некоторые. Потому что вам придется не узнать все, чему вы научились при работе с VSS, потому что VSS ... ну, это отстой.

При следующих предположениях:

• Все разработчики работают в общей кодовую во время активного развития
• У вас есть метод, по которому говорят: «Хорошо, что мы имеем здесь готовы для тестирования QA»
• Вам необходимо продолжить разработку, а также исправить ошибки для того, что находится в QA
• Как только что-то выходит на производство, вы не можете изменить то, что находится в производстве, не пройдя весь процесс (если у вас его нет, вы когда-нибудь будет беспорядок)

Я бы рекомендовал следующее:

1. Создать "традиционные" ствол/ветви/теги структуры, как описано in the manual. Все разработчики проверяют из ствола для регулярной разработки. Действительно, прочитайте всю эту главу руководства (дважды), так как это более длинная и более подробная версия того, что я здесь излагаю.
2. Когда вы решите, что пришло время отпустить выпуск в QA, создайте ветвь, скопировав соединительную линию в каталог под номером branches. Как вы это называете, зависит от вас, но будьте ясны и последовательны. Например, если вы разветвляетесь для выпуска под названием 4.2, возможно, назовите его QA-4.2 (и в следующий раз, когда вы ответите на 4.3, назовите его QA-4.3 и т. Д.).
3. Если (когда) вы обнаружите ошибки в тестировании QA, вы исправляете их как патчи против ветви QA-4.2. Тот, кто заботится об этом, должен будет проверить вторую рабочую копию, чтобы внести эти изменения и передать их филиалу.
4. Периодически слияние патчей, сделанных вами в ветке QA назад к багажнику. В противном случае те ошибки, которые вы исправили в 4.2, вернутся в 4.3.
5. Когда ваш код в QA прошел все испытания и благословлен для производства, создайте тег, скопировав ветвь QA в каталог tags. Вероятно, вы захотите быть совместимыми с тем, что вы делали в QA, с именем tags/4.2-RELEASE или чем-то близким к этому. А затем отпустите новую версию.
6. Теперь, вероятно, настало время использовать svn merge --reintegrate на вашей ветке, а затем, возможно, удалите ветку. Код был выпущен, теперь мы переходим к следующей версии.
7. Что находится в каталоге tagsне изменяется.. Если кто-то найдет ошибку в производстве, вы будете работать над ней так же, как любая новая разработка. В противном случае эти изменения не возвратятся обратно в багажник (если кто-то не смотрит действительно), и ошибка вернется.

Как сам проект Subversion create & maintain their release branches может быть информативным.