Процесс маркировки SVN с внешними
У меня есть один репозиторий.
Предположим, у меня есть LibraryX, которым я делюсь между проектами.
Предположим, что ApplicationA (среди прочих) использует LibraryX и ссылается на него как на внешнее.
Разрабатывая ApplicationA, я также, возможно, вносю изменения в LibraryX.
Предположим, что изменения были внесены как в ApplicationA, так и в LibraryX, и сейчас я делаю релиз.
Пожалуйста, сообщите мне, если вы согласны / не согласны со следующим процессом, и / или скажите, что бы вы сделали, чтобы улучшить его:
- создать тег LibraryX
- филиал ApplicationA
- измените внешние элементы в разветвленном ApplicationA, чтобы он указывал на тегированный LibraryX и, возможно, на конкретную ревизию (в случае, если кто-то в будущем сделает этот тег случайно)
- создать тег разветвленного ApplicationA
- удалить разветвленное приложение A
Звучит разумно? Есть идеи получше? Мысли?
2 ответа
Решение
Я делаю следующее:
- Я всегда ссылаюсь на библиотеку в конкретной ревизии. Если библиотека меняется, и я хочу, чтобы изменения в моем приложении, тогда я обновляю определение externals.
- На выпуске я создаю тег приложения. Мне не нужно предпринимать дополнительные шаги, поскольку указана конкретная версия библиотеки.
Некоторые дополнительные комментарии:
- Иногда я не ссылаюсь на конкретную версию библиотеки (потому что мне лень), но я знаю, что эти версии не будут пригодны для использования в будущем. Это решение, которое вы можете принять, если знаете об этом. Однако, прежде чем создать тег, я всегда замораживаю ссылку на библиотеку.
- Иногда я создаю ветку вместо тега, чтобы исправить некоторые ошибки и одновременно продолжить работу над следующим выпуском. В конце концов я создаю тег для этой ветви и удаляю эту ветку. (Возможно, я создаю более одного тега, но в конце ветка всегда удаляется.)
- Я удаляю ветки, потому что я использую ветки только как недолговечные сущности: функциональные ветки или ветки выпуска для стабилизации выпуска. Нет необходимости держать ветвь вокруг, поскольку теги - это версии, которые меня интересуют.
- Если мне нужно исправить ошибку в теге, я сначала создаю ветку. Исправьте ошибку и создайте новый тег (и удалите ветку).
- То же самое применимо, если ошибка должна быть исправлена в библиотеке (хотя и немного сложнее): в ветке вы либо обновляете библиотеку до последней версии (если это возможно), либо создаете ветку ссылочной ревизии библиотеки. Затем вы изменяете внешний элемент так, чтобы он указывал на эту ветку, исправляете ошибку в библиотеке, замораживаете определение externals до последней ревизии ветви библиотеки и создаете тег для приложения. Я обычно не пытаюсь создать тег для библиотеки, но это также возможно. Однако я удаляю ветвь библиотеки: если она когда-либо понадобится снова, вы можете создать новую ветку на основе последней ревизии удаленной ветки библиотеки.
- Тег для внешнего это пустая трата времени
- Ветка для ApplicationA + редактирование (исправление редакции LibraryX) svn:external в ветке + commit + пометить последнюю ревизию в ветке как "тег продукта"