Создайте «метку» в subversion, указывающую, какие файлы должны быть в следующем выпуске

Question

Я уже некоторое время использую StarTeam для контроля версий, но перехожу на Subversion. Я читал книгу Subversion , и, похоже, есть одна важная особенность, которой обладает StarTeam, которой нет у Subversion - концепция меток. Я знаю, что в Subversion есть ярлыки, но в StarTeam они означают что-то другое. В StarTeam я могу пометить набор файлов как «готовые к сборке», а затем только проверить их и включить в конкретный выпуск. Затем я могу создать замороженную метку, указывающую, какие файлы были включены в этот выпуск (аналогично метке Subversion, за исключением того, что она указана в этих конкретных ревизиях, но не во всех каталогах).

Есть ли способ получить такую ​​функциональность в Subversion? Я знаю, что вы можете указать, какую ревизию нужно пометить, но то, что происходит в ситуации, когда у вас есть код и вы собираетесь выпустить релиз, найти ошибку или кто-то решит, что конкретное изменение не должно быть включено. Я знаю, что вы можете создать тег на основе хранилища и вашей локальной рабочей копии, но это включает в себя проверку конкретных версий файлов, которые не должны быть включены, и создание тега. С готовым к созданию "ярлыком" вы не поместите этот ярлык в заголовок версии файлов, которые вам не нужны. Не существует автоматического способа обозначить определенные ревизии для сборки в Subversion. Это не тот случай, когда в ветке должна быть разработана новая функция, но больше, если ревизия находится в стволе (или там, где вы сделаете тег), но не должна быть включена. Возможно, его не нужно возвращать - изменение может быть уместным, но в будущем выпуске, а не в текущем. Если у вас нет конкретной ревизии с нужными версиями файлов, похоже, вам придется вручную смешивать и сопоставлять данные из репозитория и вашей рабочей копии.

В аналогичной ситуации, что если у вас есть файлы в Subversion, которые не являются частью релиза и не нуждаются в тегах. В StarTeam вы не прикрепите к ним готовую метку, но в Subversion, кажется, все в каталоге. Есть ли способ исключить такие файлы из сборки и тега? Для этого svndumpfilter исключают ?

Короче говоря, есть ли способ включить в тег только определенные ревизии определенных файлов, или это должна быть либо конкретная ревизия в хранилище, либо сочетание файлов вручную в хранилище и вашей рабочей копии?

Answer 1

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

Answer 2

Если я правильно понимаю вашу проблему, я считаю, что ее можно решить путем ветвления в какой-то момент перед выпуском (например, в момент завершения всех основных функций, которые вы хотите включить в этот выпуск), а затем тщательно управляя тем, что объединяется с этой веткой "релиз". «Основной багажник» свободен для новых вещей. Например, если ошибка обнаружена, то это может быть (а) исправлено в основной стволе, и затем принимается решение о том, следует ли ее также объединить с веткой выпуска; или (б) закреплен на ветке. Это процесс, которому мы следуем, и он работает довольно хорошо (но он также требует дисциплины и определенного количества формальных процессов).

Answer 3

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

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

Это имеет преимущества перед работой с отдельными файлами, поскольку целые наборы функций продвигаются / удаляются по мере необходимости - вам не нужно вручную искать разные файлы, удаляя изменения отсюда и там. Но для этого нужно, чтобы у вас были вменяемые коммиты и комментарии - не позволяйте вашим разработчикам коммитить с «Фиксацией в пятницу днем, чтобы все было в безопасности».

Answer 4

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

Скажем, к примеру, мы работаем в транке и выпускаем версию 1.0. Затем мы создаем ветку с именем maint-1.0, к которой никто не прикасается. Мы продолжаем разработку в стволе, и когда мы заканчиваем определенные функции или функциональность, мы перемещаем эти измененные файлы в ветку maint-1.0. Обратите внимание, что вам может потребоваться две рабочие копии и просто скопировать измененные файлы. Выполнение фактического слияния потребует объединения всех изменений, а не только отдельных файлов.

Конечным результатом является то, что ваша ветка maint-1.0 содержит только те изменения, которые вы хотите внести в следующую сборку.

Answer 5

Subversion только позволяет атомарно пометить всю ревизию исходного дерева. Требуемая функциональность требует некоторой связи между системой контроля версий и системой тикетов, которая поддерживает не только внесенные изменения, но и файлы, которые были изменены для каждого тикета

Trac, например, анализирует журналы фиксации для каждой ревизии, чтобы связать их с любым количеством заявок, используя синтаксис # в журнале фиксации.

Вам потребуется модуль, который будет поддерживать заявки, связанные с новым выпуском, а затем вычислять, какие файлы будут включены в пакет дельта-выпуска.