Позвольте мне в качестве предисловия сказать, что я не знаком со StarTeam, поэтому я могу не полностью понять рабочий процесс, который вы пытаетесь воспроизвести.
Сама Subversion не различает теги и ветви.По соглашению, тег - это просто ветка, которую вы никогда не модифицируете.Даже ветвь - это просто операция «svn copy», отдельной функции «ветка» не существует.Ветвь - это просто дешевая копия, а тег - это ветка, доступная только для чтения по соглашению.Копии в SVN очень дешевы, поэтому вам не нужно много беспокоиться о создании веток - тег не дешевле, чем ветка.Возможно, вы захотите прочитать документы по Создание филиала .Кроме того, он объясняет некоторые вещи ... и имеет коробочный раздел о «дешевых копиях».
В зависимости от того, как вы используете «View Labels» в StarTeam, возможно, что svn externals может бытьполезно для ваших целей.Мне они вообще не нравятся, но это зависит от сценария.
Относительно ваших вопросов ...
1) Это будет зависеть от других изменений в файле.,Хотите ли вы внести изменения из одной ревизии в один файл?Или все изменения для 1 файла (несколько ревизий, только 1 файл).Надеюсь, вы имеете в виду первое.В этом случае обычным поведением будет слияние
Допустим, у вас есть следующий сценарий:
------------------------------------> /trunk
| | fix merged to 1.0 branch
| v
\------------> /branches/1.0
| ^ |
| \ /tags/1.1 1.1 tag, fix released to customer(s)
\ /tags/1.0 - 1.0 GA tag, release sent to customer(s)
Вы разрабатываете на транке.На 10 версии ваш продукт уже готов к отправке 1.0!Вы создаете ветку с:
svn copy /path/to/trunk /path/to/branches/1.0
Затем вы продолжаете разработку на стволе, одновременно выполняя небольшую дополнительную проверку на ветке 1.0.Когда он будет готов к отправке, вы создаете тег:
svn copy /path/to/branches/1.0 /path/to/tags/1.0
Этот тег является замороженным моментом времени, который точно соответствует тому, что вы отправляете покупателям.
Вы обнаружили ошибку /функция / обновление, необходимое для ваших клиентов версии 1.0, которое уже было сделано на транке.В вашем случае вы указали изменения в конкретном файле.
Допустим, изменения произошли в стволе в ревизии 15. Затем вы сделаете (из чистой рабочей копии /branches/1.0):
svn merge -c 15 /url/to/repo/path/to/trunk
В идеальном случае изменения ревизии являются автономными, и все файлы в ревизии необходимы.Иногда есть и дополнительные вещи, которые вы не хотите объединять.В этом случае после слияния верните изменения в файлы, которые вы не хотите объединять, протестируйте все и затем подтвердите.У слияния есть и обратная сторона -> вернуть некоторые файлы -> рабочий процесс коммита, который заключается в том, что subversion будет записывать слияние как происходящее, но вы исключили его части.Если рассматриваемая ветка вряд ли изменится (или реинтегрируется в другую ветвь), это может не иметь значения, но я предпочитаю создавать файл исправлений для изменений в нужном вам файле 1 и применять их к ветке вручную для случаевкак это.Я не уверен на 100% в синтаксисе строки cmd, но я думаю, что он будет очень похож:
svn diff -c 15 / path / to / file (в репозитории или другой рабочей копии)> my-patch.diff
и применить с другим инструментом.Я обычно создаю / применяю патчи в графическом интерфейсе, поэтому подробности будут оставлены для вас в качестве упражнения.
После этого вы снова создадите новый тег на своей ветви, который будет содержать ваше новое объединенное изменение..
svn copy /path/to/branches/1.0 /path/to/tags/1.1
Затем у вас есть новый тег, который совпадает со старым тегом, за исключением того, чтоизменения в 1 файл.В # 3 я также упомяну, что вы можете воссоздать тег (хотя это зависит от того, для чего вы используете тег, от того, является ли это хорошей идеей).r, но я бы сделал это только в том случае, если тег не представляет отправленный код.
2) Действительно, поскольку условно тег только для чтения, тег из другого тега не будет отличаться. Однако, если вы вместо этого используете ветку для первого, а затем создаете тег, который (как предлагается), вы можете позже создать второй тег на основе той же ветви (после внесения дополнительных изменений), и он будет отличаться от вашего первого помечать только изменения, которые были применены к этой ветви с тех пор.
3) Опять же, вы обычно используете ветку. Если ветвь / тег используется исключительно для внутреннего использования (я не рекомендую когда-либо удалять тег выпуска выпущенного кода, хотя на самом деле он не "утерян", обычно это просто не нужно -), Вы можете просто удалить и восстановить тег. Потребители вашего тега (рабочие копии) могут просто выполнить обычное «обновление svn» после удаления и повторного создания тега и продолжат нормально работать, как будто ничего не произошло. Это не может быть использовано для # 1, но может быть для # 2, когда вы действительно хотите обновить тег. Хитрость заключается в сочетании тегов и ветвлений для достижения того, что вы хотите. Если вы также используете это для развертывания на веб-сайте или чем-то еще, вы можете комбинировать ветвление, тегирование и внешние элементы.
например. / path / to / production может быть извлечен, который имеет внешнюю запись в /tags/1.0, и когда вы хотите применить исправление, вы выполняете шаги в # 2 и создаете /tags/1.1 и корректируете внешнюю запись. Или просто наведите указатель на ветку и не нужно заново создавать теги.
Надеюсь, это полу-полезное начало.