войти зарегистрироваться

Разработка whois

индекс
174,05

Правильный цикл работы с версиями SVN

Я думаю многие любопытные люди уже знают, как нужно верно работать с SVN.
Но во многих статьях это описано достаточно поверхностно. Хочется немного приоткрыть завесу верного цикла версионирования, при разработке проекта, на примере TortoiseSVN.
И так, поехали

Шаг 1. Создание ветви (branch).
Для этого вам нужно создать рабочую копию версии trunk. Далее, чтобы создать ветвь жмём правой кнопкой на данной копии и в контекстном меню выбираем TortoiseSVN -> Branch/tag

В появившеся диалоговом окне введите адрес ветви (самое главное — не создавайте каталог, TSVN сам всё сделает). Так же обязательно введи короткое описание ветви (это является очень хорошим тоном). Если вы сразу хотите приступить работать с ветвью, то отметьте Switch working copy to branch/tag. Тогда ваша рабочая копия будет являться копией, находящейся на сайте

Вот и всё. Ветвь готова.
Шаг2. Возвращение в trunk
Этот шаг для многих очень тяжёлый для начинающих. Чтобы ваши изменения появились в trunk (а они должны там появиться) нужно произвести операцию, известную как Merge.
Итак, поехали.
Создайте обособленно от всех ваших текущих рабочих копию ещё одну копию trunk. Это делается для того, чтобы ваша текущая рабочия копия и её изменения не побились.
На рабочей копии, в контекстном меню, найдите TortoiseSVN -> Merge:

Выберите Merge a range of revisions в появившемся диалоговом окне. Если такого окна не появилось — значит пора обновить TSVN.

Reintegrate a branch тоже справедлива, то есть одно но — далеко не все svn-сервера способны с этим работать (у меня, к сожалению, пока, заставить не получилось). Поэтому мы и воспользуемся проверенным и работающим везде методом.
В новом диалоговом окне нужно нужно указать путь до вашей ветви (URL to merge from) и диапазон ревизий.
Важно! Не указывайте лишь HEAD ревизию — в данном случае сливаться эти версии будут от первой до последней ревизии. Практика показала, что страшного ничего не произойдёт, но всё-таки лучше предостеречься. К тому же, если указать ревизии, то это будет просто быстрее.

В следующем диалоговом окне опции уже идут по вашему усмотрения (но прежде ознакомьтесь со справкой по TSVN). Если вы не уверены, то вы можете посмотреть предварительный результат при помощи кнопки Test Merge. По нажатию на Merge произойдёт слитие всех изменений из ветви в вашу рабочую копию trunk.
Теперь осталось исправить конфликты, убедиться что всё хорошо и делать commit вашей рабочей версии trunk на сервер.
Я весьма советую указывать ревизии, которые вы мержили, в логе сообщений. Так вы не потеряетесь среди ревизий, а для членов вашей комманды будет указатель.
Формат примерно такой:
5000-5010 from ARTICLE1
5000-5010 — это ревизии, ARTICLE1 — имя ветви.
Ну вот и всё. Когда работа на ветвью завершена — данный цикл начинается вновь.
Некоторые утверждают, что после окончания работы с бранчем, его нужно удалить. Здесь уже решайте сами
С уважением, blog.artsofte.ru
Удачи в разработках!
+36
29 октября 2008, 10:56
maddogg

комментарии (53)

  • Спасибо, давно хотел попробовать svn вместо vss и tfs, сравнить, что удобнее лично для меня.
    • попробуйте git или mercurial
      • Где взять скомпилированный GIT для Windows?
      • Как по мне, с svn работать намного проще чем с git, скачивание отдельно выбранных ревизий, написание патчей, удобный клиент — TortoiseSVN. Но git предоставляет больше возможностей по управлению проекта в целом. Скорее всего на меня сказывается привычка работы с svn. Большой проблемой при попытки перехода на git было отсутствие нормального(с точки зрения svn'шика) нумерации изменений.
        • а мне git куда проще, точнее вначале было конечно тяжеловато врубиться и начать использовать его не в svn-стиле, но потом разобрался, если хотите разобраться, то вот book.git-scm.com
          • Спасибо, почитаю. Надеюсь узнаю много чего нового и интересного, и вернусь к идеи перехода на git. Просто тогда я не нашел(видимо плохо искал) инфу о гит'е, и пришлось все осваивать практически самому.
    • а мне кажется, что в tfs намного удобнее, мне так кажется :)
      • Вот мне и хочется попробовать разные и посравнивать. :)
        Как говориться, лучше 1 раз увидеть.
  • Собственно, тоже самое написано в мегакниге по subversion, только без привязки к конкретному клиенту.

    Ссылка на главу о ветвлениях и слияниях была бы в посте не лишней.
    • данный момент у меня просто немного наболел. Хотелось поделиться быстрым и кратким решением.
      ветвления это вообще отдельная история. Я вот копаюсь в архивах хабра — может уже есть на самом деле такая статья
  • «Правильный цикл работы с версиями в SVN» или «Правильный цикл работы с версиями в системе контроля версий».

    Не кажется что тавтология какая-то. Я вот глазами пробежал и нифига не понял о чем пост. Я уж было подумал что тут методика описана как когда и почему делать или не делать ветви. Разные подходы там. Поместили бы подробное описание проблемы вначале хотя бы… примеры какие-нибудь…
  • Спасибо за статью. Думаю пригодиться в ближайшем будущем.
  • Хочу обратить внимание, что номера ревизий, которые надо перекинуть в trunk указываются невключительно. Первая цифра — это номер ревизии, с которой надо начать объединение (merge), а вторая — это номер ревизии, следующей за последней объединяемой ревизией (т. е. на единицу больше).
    • тьфу. мало того, что не дал предпросмотр сделать, так еще и продублировал. Так еще и криво отформатировал :)
  • Хочу обратить внимание, что номера ревизий, которые надо перекинуть в trunk указываются невключительно. Первая цифра — это номер ревизии, с которой надо начать объединение (merge), а вторая — это номер ревизии, следующей за последней объединяемой ревизией (т. е. на единицу больше).
  • У меня Reintegrate a branch зарабоатело после обновления свн сервера до 1.5 и последующего апгрейда репозитария с помощью команды svnadmin upgrade <имя репозитория>
    • Да использовать «Reintegrate a branch» в TortoiseSVN намного лучше, чем запоминать номера замердженных ревиизий в логе.

      Недавно сами перешли на 1.5, стало намного удобней работать светками.
  • Мдя. Посмотришь на такое и сразу хочется волевым решением перевести все проекты на git.
    • С большими проектами git пока хуже справляется, чем svn. К тому же, merge tracking в svn уже есть.
      • А какже Linux с его 100 млн. строк кода? :)

        Проблемы git больше со стилем работы — они в git и svn совместимы также, как стиль работы в svn и cvs. Я для себя определился: svn для централизованной разработки в конторе, в том числе, в стиле «кинул файл и забыл», а git — для сетевых FOSS-проектов, когда каждый модуль (репозитарий) — корректный законченный компонент с Makefile и прочими прелестями.
        • 100 млн. строк кода в ядре?? Тут более точная оценка: linux.slashdot.org/article.pl?sid=08/10/22/1713241

          А вообще да, я имел в виду монолитные большие проекты внутри одной конторы.
          • Да, я ошибся на порядок. :)
  • Хочу обратить внимание, что номера ревизий, которые надо перекинуть в trunk указываются не включительно. Первая цифра — это номер ревизии, с которой надо начать объединение (merge), а вторая — это номер ревизии, следующей за последней объединяемой ревизией (т. е. на единицу больше).
    • о млин… ссори, я не хотел :(
  • Странная претензия на правильностью Что тут правильного? Вы уверены в том что организация репозитария как у вас единственный правильный подход?
    • ну да. Лучше весь код хранить в trunk и мешать друг другу при разработке.
      А по сути вашего вопроса — да, я уверен что существует не один подход к организации репозитария. Любой вопрос в сфере IT можно решить далеко не одним способом, а потом препираться и устраивать холивары на эту тему.

      Я предложил, скажем так, один из распространённых методов организации, который описывается не в одном мануале. Просто я решил немного уделить внимания подводным камням, с которыми столкнулся я, с которыми столкнулись знакомые программисты. И видимо столкнутся и остальные, кто ещё о данной технике даже не задумался
      • Судя потому что Вы мне ответели, Вы мало читали документации на subversion, что тем более снижает компетентность Ваших слов.

        ЗЫ. trunk'a может и не быть ;)
  • Имхо, цикл неполон. Более подробное изложение, если угодно.
    • Спасибо!
    • отличная статья
      спасибо
    • Супер. Стиль изложения напорядок выше чем в статье на хабре.
  • Не совсем правильный цикл вообще-то. Не описана связь между branches и tags
  • Я бы не назвал описанный подход «правильным», я бы его назвал «простой пример». Если кто-то начнёт длительный или серьёзный проект подобным образом, он неизбежно наступит на грабли с бранчами и мержингом. Мы столкнулись и довольно болезненно разгребали.

    Ещё я бы добавил аналогичные команды для оригинальной команды svn (для полноты картины), а также ссылку на Subversion book и на её перевод на русский.
  • Стиль автора напоминет стиль промта.
    • Ага, особенно вот этот кусок:
      Создайте обособленно от всех ваших текущих рабочих копию ещё одну копию trunk
  • >В новом диалоговом окне [b]нужно нужно[/b] указать путь

    Очень нужно!
    • vp7
    • vp7
    • 29 октября 2008, 19:36
    • #
      • +1
    Спасибо!
    Некоторое время назад перешел с CVS на SVN — стало заметно удобней.
    Но Branch'ами не пользовался, спасибо за подсказку!
    • кииииборги заполонили всю планету, кииборги, они :)
  • Тема не раскрыта.
  • мне кажется, вся наработанная программерами куча должна лежать в trunk, а ветки, отходящие от него должны быть как раз стабильными версиями.
    сделал у себя локально -> там же протестил -> выложил в транк -> там его проверили тестеры -> если все ок, то выкладываются в ветку со стабильной версией.

    вроде как удобнее. нет?

    а так вообще статья — много буков и картинок, да не по делу все, в основном.
    • Для стабильных версий обычно делают tags. А бранчи нужны для работы в рамках определенной задачи с последующим слиянием кода в trunk. Бранчи удобны в ситуации, когда нужно переключиться с разработки фичи А на разработку фичи Б: вы просто делаете switch с бранча А на бранч Б, а по окончанию работы с таском Б, вы можете вернуться к работе над А.

      Если в очередной релиз будет решено отложить фичу А — вы просто не мержите код бранча А в trunk — и получаете релиз без фичи А. Т. е. trunk всегда содержит «стабильный» код, который, в идеале, в любой момент можно забрать из SVN, сбилдить и получить рабочую версию проекта.
      • спасибо, так действительно удобнее.
      • документация рассматривает два подхода: «стабильный транк» и «стабильный бранч»
        какой использовать — вероятно, политика команды и компании
    • Есть разные подходы. Первый: «trunk — это куча, но стабильная, готовая, что бы в любой момент от неё можно было отфоркать релиз», второй — «куча-полуфабрикат для черри-пикинга в релизные ветки». В обоих подходах все нетривиальные фичи разрабатываются в фича-брэнчах.
  • давно пользуюсь SVN — отличнейшая весчь.
  • благодаря вашему посту таки решился и выделил время на подробное прочтение раздела официальной документации свн о бранчах :-)
  • Признаться, ожидал увидеть статью с объяснением основных понятий и описанием базовых принципов работы с ветками. А уже затем должны идти пошаговые инструкции с картинками. Это бы сильно повысило ценность материала.
  • Прочитав статью заметил один факт, который никак не укладывается у меня в мозгу, как у разработчика, почему надо работать с бранчами, а потом, прости Господи, мержится. Для многих — это, так сказать, ТРУ путь, но мержинг это штука очень противная и неприятная. С теми свн, с которыми я работал — дело происходило следующим образом, все работают исключительно с транком, в таком случае мерджинг происходит очень редко. Смоделирую ситуацию. Ты пишешь обширный модуль (30+ классов) который работает с низкоуровневыми модулями системы (которые постоянно обновляются, правятся и т. п). Естественно, что до завершения тестирования ты свое творение в транк не зальешь, а при заливке приходится мержить только общие (см. выше) файлы. А если вести разработку в своей ветви то придется мержить все. Итого что мы имеем:
    1 — работа с бранчем = Мерж всех общих файлов и мерж своих (все 30+ файлов)
    2 — работа с транком = Мерж только общих файлов (~ 5-7 файлов)

    По времени 2 способ куда более безболезненный (это плюс). Но есть и минусы, первый и очевидный минус при работе только с транком — все твои изменения хранятся только локально, что есть не совсем гуд, если нет уверенности в железе. Для большинства это огромный минус. Но мне, наверное, очень повезло. Я работаю с макосью и любимая машина времени (Time Machine) постоянно (раз в 3 часа) бекапит _ВСЕ_ измененные файлы.

    Выводы: Если есть система локального _тихого_ бекапа можно с чистой совестью работать с транком, если ее нет — добро пожаловать в бренчинг/мерджинг.
    • хотя, если посмотреть как можно обще — моя система это, вообщем, тот же бренчинг, но без ужасного мерджинга :)
    • Особенно наверное весело когда в создании «творения» принимают участие несколько разработчиков. В git с этим на порядок лучше
      • 5+ разработчиков хватит?
Только авторизованные пользователи могут оставлять комментарии. Авторизуйтесь, пожалуйста.