Subversion - Ветвление / Слияние - PullRequest
1 голос
/ 09 февраля 2011

У меня есть базовые навыки ветвления и слияния в SVN.Вы ветвитесь, делайте все что угодно, сливайтесь обратно с транком.

У вас есть , чтобы слиться обратно с транком?

Мой сценарий:

У меня есть небольшие приложения в ASP.NET MVC2, использующие Linq to SQL.С выходом MVC3 я собираюсь либо обновить его до MVC3, либо переделать с нуля (используя EF 4).В любом случае, следующая «версия» будет сильно отличаться от того, что у меня есть сейчас.

Мне интересно, как мне обращаться с SVN-частью.Должен ли я поместить его в SVN как ветвь текущего репозитория (/ svn / project / trunk / mvc3) или запустить новый репозиторий (/ svn / project_mvc3 / trunk).

Ответы [ 3 ]

2 голосов
/ 09 февраля 2011

Храните его в том же хранилище. История исходного кода не относится к «версиям» (релизам) для людей.

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

1 голос
/ 10 февраля 2011

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

Звучит так (извините, если я неправильно понял), что вы считаете управление версиями носителем информации дляваш код, но это может быть гораздо больше, чем это.Он наиболее эффективен, когда несколько пользователей вносят изменения в код.Частично ветвление дает вам эту функциональность.

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

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

Таким образом, ответ на вопрос, вероятно, таков: «Это зависит».Что для вас делает контроль версий?Почему вы поместили приложение в систему контроля версий?Если ответы на эти вопросы по-прежнему применимы к новой версии и, что особенно важно, применимы к эволюции приложения от одной версии к другой, то, вероятно, правильное решение - это ветвление / слияние.

Кстати, если выЕдинственный разработчик приложения, тогда нет необходимости разветвляться и объединяться, если только вам не нужно поддерживать транк в течение периода, в течение которого происходит ветвление.Это может быть в том случае, если ствол где-то находится в производстве, и вам необходимо применить исправления ошибок при разработке ветки.

И последнее (если немного касательное) замечание - ветвь и ствол в основном простоподпапки в Subversion.Вы можете объединить любой путь (от линии к ветви, или ветви к линии).

1 голос
/ 10 февраля 2011

Если вы хотите сохранить то, что у вас есть, но будете вносить существенные изменения, которые вы хотите использовать для продвижения вперед, я бы предложил создать ветку для вашего текущего проекта и поместить ваши новые изменения в транк. Например (/ svn / project / branch / mvc2) может содержать ваш текущий проект, а (/ svn / project / trunk) может означать, что MVC3 движется вперед.

...