Процесс маркировки SVN с внешними - PullRequest
Новая
       29

Процесс маркировки SVN с внешними

2 голосов
/ 05 октября 2011

У меня есть один репозиторий.

Предположим, у меня есть LibraryX, которым я делюсь между проектами.

Предположим, что ApplicationA (среди прочих) использует LibraryX и ссылается на него как на внешнее.

При разработке ApplicationA я также, возможно, вносю изменения в LibraryX.

Предположим, что были внесены изменения как в ApplicationA, так и в LibraryX, и сейчас я делаю релиз.

Пожалуйста, сообщите мнеесли вы согласны / не согласны со следующим процессом и / или сообщите мне, что бы вы сделали для его улучшения:

  • создайте тег LibraryX
  • ветвь ApplicationA
  • измените внешние элементы в разветвленном ApplicationA, чтобы он указывал на помеченный LibraryX и, возможно, на конкретную ревизию (в случае, если кто-то в будущем сделает это случайно)
  • создайте тег разветвленного ApplicationA
  • удалить разветвленное приложение A

Звучит разумно?Есть идеи получше?Мысли?

Ответы [ 2 ]

4 голосов
/ 05 октября 2011

Я делаю следующее:

  • Я всегда ссылаюсь на библиотеку в определенной ревизии. Если библиотека изменяется, и я хочу, чтобы изменения в моем приложении, тогда я обновляю определение externals.
  • При выпуске я создаю тег приложения. Мне не нужно предпринимать никаких дополнительных действий, поскольку указана конкретная версия библиотеки.

Некоторые дополнительные комментарии:

  • Иногда я не ссылаюсь на конкретную версию библиотеки (потому что я слишком ленив), но я знаю, что эти версии не будут пригодны для использования в будущем. Это решение, которое вы можете принять, если знаете об этом. Однако перед созданием тега я всегда замораживаю ссылку на библиотеку.
  • Иногда я создаю ветку вместо тега, чтобы я мог исправить некоторые ошибки и в то же время продолжить работу над следующей версией. В конце концов я создаю тег для этой ветви и удаляю ветку. (Может быть, я создаю более одного тега, но ветка всегда удаляется в конце.)
  • Я удаляю ветки, потому что я использую ветки только как недолговечные сущности: функциональные ветки или ветки выпуска для стабилизации выпуска. Нет необходимости держать ветвь вокруг, поскольку теги - это версии, которые меня интересуют.
  • Если мне нужно исправить ошибку в теге, я сначала создаю ветку. Исправьте ошибку и создайте новый тег (и удалите ветку).
  • То же самое применимо, если ошибка должна быть исправлена ​​в библиотеке (хотя и немного сложнее): в ветви вы либо обновляете до последней библиотеки (если это возможно), либо создаете ветку ревизионной ссылки библиотеки. Затем вы изменяете внешний элемент так, чтобы он указывал на эту ветку, исправляете ошибку в библиотеке, замораживаете определение externals до последней версии ветки библиотеки и создаете тег для приложения. Я обычно не пытаюсь создать тег для библиотеки, но это также возможно. Однако я удаляю ветвь библиотеки: если она когда-либо понадобится снова, вы можете создать новую ветку на основе последней ревизии удаленной ветки библиотеки.
0 голосов
/ 07 октября 2011
  1. Тег для внешнего - пустая трата времени
  2. Ветка для ApplicationA + редактирование (исправление редакции из LibraryX)1004 *
...