Организация SVN филиалов с помощью TortoiseSVN

Question

Как организовать филиалы в системе SVN? Я использую TortoiseSVN, так как я использую Windows.

В настоящее время у меня есть такая структура файлов / каталогов. Я несколько привык к управлению нумерованными версиями, хотя не вижу полной картины того, как работает эта система управления.

program_main\trunk\corefile.php
program_main\tags\1.0\corefile.php
program_main\tags\1.1\corefile.php
program_main\tags\1.2\corefile.php

Теперь я хотел бы сделать еще одну программу на его основе. Это будет отдельная программа, но она использует основную программу в качестве своей базы. Если основная программа обновляется, расширенная измененная программа также обновляется с соответствующим номером версии.

program_mod\trunk\corefile.php
program_mod\trunk\additionlalfile.php
program_mod\tags\1.0\corefile.php
program_mod\tags\1.0\additionalfile.php
program_mod\tags\1.1\corefile.php
program_mod\tags\1.1\additionalfile.php
program_mod\tags\1.2\corefile.php
program_mod\tags\1.2\additionalfile.php

Когда я щелкаю правой кнопкой мыши на папке ствола основной программы и выбираю TortoiseSVN -> Branch/Tag и указываю путь к /program_main/branches/program_mod/1.0 , он пытается загрузить файлы в папку филиала в главном каталоге проекта на публичный сервер. Основная директория проекта общедоступна и видна всем, я бы не хотел загружать модифицированную (ветвь) версию на этот сервер.

В этом случае, как я должен делать? Я предполагаю, что это должна быть очень простая операция с использованием команды слияния или чего-то еще.

Спасибо за ваш совет и информацию.

Answer 1

Некоторые заметки

• Организация дерева репозитория, функции различных узлов внутри репозитория Subversion - это просто вопрос соглашений, "лучших практик" и привычек, и они строго связаны со стилем работы, а не используются инструментами на стороне клиента для доступа к репозиторию. Т.е. "использование TortoiseSVN" не относится к информации в свете вашей задачи (такая же / найденная и удовлетворенная / техника будет | может использоваться с любым svn-клиентом в любой ОС)

• Ваша бизнес-задача должна быть определена (лучше и правильнее, из моего POV) не как "как использовать ветви", а как «как хранить и связывать связанные проекты в случае Subversion SCM-backend», где используются ветви (или любая другая иерархия внутри репо) это только один и не лучший (IMNSHO) выбор

Решения

Subversion externals

Любая часть SVN-репозитория, которую необходимо клонировать в любое другое место (и сохранить связь между клоном и оригиналом в будущем), может быть использована в svn:externa l trick. Таким образом, мы добавим в хранилище "виртуальное дерево", которое где-то существует каким-то образом, но может появиться в WCout с надписью как часть нашего хранилища.

(на этой фотографии транк-каталог является внешним по отношению к независимому репо)

Ваша текущая плоская структура program_mod

dir /B

corefile.php

additionalfile.php

налагает ограничение на версию Subversion (как на стороне клиента, так и на стороне сервера), потому что внешние файлы были добавлены только в Subversion 1.6, для внешних каталогов

dir /B /S

г:\ мод \ additionalfile.php

г:\ мод \ Ядро

г:\ мод \ Ядро \ corefile.php

более ранние версии также могут быть использованы. Последний вариант также имеет еще одно небольшое преимущество с точки зрения управляемости в случае расширения основного проекта в многофайловый проект: в случае внешних файловых файлов вам придется добавлять каждый новый файл вручную, внешние каталоги. будет включать все файлы внутри внешнего объекта

Филиалы и слияния

С другой стороны вы можете использовать метод слияния веток для поддержки program_mod

Разветвите источник ядра (/trunk) на какой-либо отдельный узел внутри репозитория (branches/program_mod , fe). Добавьте дополнительный файл.php в эту ветку. После каждой магистральной фиксации / лучше / или перед выпуском program_mod / хуже / объединить транк в ветку program_mod (или svn copy corefile в ловушку после фиксации - TBT!)