Продвинутые методы подрывной деятельности, что я пропускаю?

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

Например

Я хотел бы иметь возможность помещать на карантин любые изменчивые / серьезные изменения в какой-то «суб-репозиторий» или что-то еще. Я обнаружил, что серьезные изменения препятствуют исправлению небольших ошибок, которые являются срочными. Как я могу отправить одно простое обновление, не выдавая неполный или сломанный код?

Чтобы рассмотреть ваш пример, у вас есть три возможности сделать это:

1. Вы можете зафиксировать отдельные файлы. Если вы используете IDE для доступа к репозиторию, скорее всего, у него есть представление, чтобы выбрать или отменить выбор отдельных файлов перед фиксацией. В командной строке вы вводите svn commit file1 path1/file2 path2для подтверждения файл1, путь1 / файл2 и каждое изменение в пути2.
2. Вы можете сделать разные рабочие копии. Вы работаете над своей большой функцией в своей стандартной рабочей копии и получаете информацию о срочной ошибке. Вы можете извлечь свой репозиторий в другой каталог и исправить ошибку во второй рабочей копии. Вы даже можете проверить только подкаталог с компонентом, в котором возникает ошибка. После исправления вы можете зафиксировать свою вторую рабочую копию без фиксации своей работы над большой функцией. РЕДАКТИРОВАТЬ: Этот способ также описан в ответе Анны Лир.
3. Вы создаете ветку для работы над вашей функцией. Для этого вы используете команду копирования. Если вы используете стандартный-макет для вашего хранилища (каталоги с Projectname и подкаталоги с именами хобот, теги и ветви, ствол , содержащий проект) , вы можете использовать СВН-копировать-команду как следует создать ветвь: svn copy svn://hostname/projectname/trunk svn://hostname/branches/branch-for-feature-X. Теперь вы можете переключить вашу рабочую копию на новое место: svn switch svn switch svn://hostname/projectname/branches/branch-for-feature-X. Если вы переключаетесь в режим исправления ошибок, вы фиксируете свои фактические изменения, переключаете свою рабочую копию обратно в транк, исправляете ошибку и фиксируете и переключаете рабочую копию обратно в свою ветвь функции. Если вы готовы к разработке функции, вы можете объединить ее обратно в ствол.

Для описанного простого случая вы обычно будете использовать # 1 (я использую чаще всего), иногда # 2. Работа с ветками (случай № 3) более сложна ( подробнее ), но допускает больше хитростей. Но ветки, соответствующие вашему описанию, находятся в репозитории.

Кроме того, из вашего примера я не могу сказать много. В Subversion есть много вещей, но я не знаю, что вы уже используете и что вам нужно для вашего проекта. Чтобы узнать больше о SVN, SVN-Book - отличный ресурс: http://svnbook.red-bean.com/

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

Таким образом, вы можете иметь структуру папок, которая выглядит примерно так:

D:\Dev\MajorFeature1
D:\Dev\Bug12345
D:\Dev\MajorFeature2

и т.п.

Все они могут быть извлечены из того же места в вашем SVN, например http://mysvnrepo/trunk.

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

Вы смотрели на Subversion Branches вообще?

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

Другой подход заключается в том, чтобы иметь ветку для определенного выпуска, чтобы избежать любой другой работы, случайно выполняемой в стволе, вызывающей проблемы. Вы можете исправить ошибку 'Release Branch' по мере необходимости, а затем сложить эти исправления обратно в ствол, когда будете готовы.

Ваши разработчики могут иметь несколько рабочих копий - ствол и любые ветви - или могут переключаться между стволом и конкретной веткой с помощью svn switchкоманды.

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

Текущий размер моей рабочей копии - 10 ГБ, с более чем 50 000 файлов. У меня может быть несколько копий для разных веток, но для создания новой копии требуется время!

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