Концепции Subversion для пользователя StarTeam

Позвольте мне начать с того, что я не знаком с StarTeam, поэтому я не могу полностью понять рабочий процесс, который вы пытаетесь воспроизвести.

Сама Subversion не делает различий между тегами и ветвями. По соглашению, тег - это просто ветвь, которую вы никогда не изменяете. Даже ветвь-это просто операция копирования svn, нет отдельной функции "ветвь". Ветвь-это просто дешевая копия, а тег-это ветвь, доступная только для чтения по соглашению. Копии в svn стоят очень дешево, так что вы не можете нужно много беспокоиться о создании ветвей-тег не дешевле, чем ветка. Вы можете прочитать документы по созданию ветви . Это еще больше все объясняет... и имеет коробочный раздел о "дешевых копиях".

В зависимости от того, как вы используете "метки вида" в 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. Вы бы тогда сделали (из чистого / ветви / 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 копировать /путь/до/филиалов/1.0 /путь/к/теги/1.1

Затем у вас будет новый тег, который будет таким же, как и старый тег, за исключением изменений в файле 1. В #3 я также упомяну, что вы можете воссоздать тег (хотя это зависит от того, для чего вы используете тег, является ли он хорошим идея). r, но я бы сделал это только в том случае, если тег не представляет отправленный код.

2) Действительно, поскольку по соглашению тег доступен только для чтения, тег от другого тега на самом деле не будет отличаться. Однако если вместо этого вы используете ветвь для первой, а затем создаете тег, который (как было предложено), вы можете позже создать второй тег на основе той же ветви (после внесения дополнительных изменений), и он будет отличаться от вашего первого тега только теми изменениями, которые были применены к этой ветви с тех пор. затем.

3) опять же, вы обычно используете ветвь. Если ветвь / тег используется исключительно внутренне (я не рекомендую когда - либо удалять тег выпуска отгруженного кода, хотя он на самом деле не "потерян", это просто не должно быть необходимо -), вы можете просто удалить и воссоздать тег. Потребители вашего тега (рабочие копии) могут просто сделать обычное "обновление svn" после удаления и повторного создания тега и будут продолжать работать нормально, как будто ничего не произошло. Это не может быть использовано для #1, но может быть для #2, когда на самом деле вы просто хотите обновить тег. Хитрость заключается в том, чтобы объединить теги и ветвления для достижения того, что вы хотите. Если вы также используете его для развертывания веб-сайта toa или чего-то еще, вы можете комбинировать ветвление, теги и внешние компоненты.

Например, можно проверить /path/to/production, который имеет запись externals в /tags / 1.0, и когда вы хотите применить исправление, вы выполняете шаги в #2 и создаете /tags/1.1 и корректируете запись externals. Или просто направьте его на ветку и нет нужно воссоздать теги.

Я надеюсь, что это полуполезное начало.