Слияние ошибок в ветках релиза - svn переключиться на ветку или получить отдельную рабочую копию?

Question

Я относительно новичок в Subversion, надеясь получить информацию от более опытных людей. Мы используем подход, заключающийся в том, чтобы выполнить основную часть работы по разработке (новые функции и исправления ошибок) в стволе и при необходимости объединить исправления ошибок в ветки выпуска. При таком подходе разработчики вообще не будут кодировать непосредственно ветки релизов, а только сливаются в них.

Моей первой мыслью было, что, возможно, разработчикам вообще не нужна рабочая копия веток релиза, и, возможно, изменения в стволе могут быть объединены в ветки непосредственно в репозитории. Но я быстро понял, что Subversion работает не так - вам нужна рабочая копия для объединения.

Таким образом, моя следующая мысль была о том, что разработчики могут по-прежнему сохранять только одну копию кодовой базы локально, указывать ее на ствол и делать svn-переключение на ветку релиза, когда им нужно выполнить слияние. Пара потенциальных проблем, которые я мог предвидеть:

1. Может быть слишком легко забыть svn переключиться обратно на транк после слияния.
2. Разработчик может иметь незафиксированные изменения в своей рабочей копии (что-то, над чем они работали в будущем выпуске до того, как его прервали для работы над исправлением ошибки), которые все еще будут присутствовать при переключении svn и случайно объединить изменения в ветке релиза.

Если бы я собрал несколько сценариев для этого процесса, я мог бы предотвратить появление проблемы № 1, но № 2 беспокоит меня немного больше. Мне интересно, не нарушит ли это подход.

В двух словах, мой вопрос таков: при объединении исправлений ошибок из ствола в ветку релиза, где у разработчика еще нет рабочей копии ветки релиза, считается ли это лучшей практикой для разработчика Переключатель SVN, чтобы сделать слияние, или проверить рабочую копию ветки релиза в другом месте локально? Заранее спасибо!

Answer 1

Я бы не использовал svn switch, за исключением случайных обстоятельств (как описано в документации), когда вы начинаете кодировать решение для одной ветви (скажем, транка), а затем решаете, что было бы лучше в своей собственной ветви (svn copy trunk) newbranch; svn switch newbranch).

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

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

Answer 2

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

Answer 3

Я часто использую функцию разреженного оформления SVN. Если я проверяю репозиторий, я проверяю папки trunk / tags / releases не рекурсивно (непосредственные потомки, включая папки). Затем я вхожу в каждый из них и обновляюсь, чтобы их непосредственные дети тоже были проверены. Таким образом, у меня есть полный обзор всего хранилища, не тратя слишком много места на диске.

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

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

Мне еще не приходилось сталкиваться с хранилищем, в котором количество тегов или ветвей настолько огромно, что просто проверка папок не рекурсивно тратит пространство.

Answer 4

Это довольно философский вопрос. Чтобы избежать проблемы № 2, я бы, вероятно, пошел с отдельной проверкой для слияния. Это может занять немного больше времени, но это определенно более гибко.