SVN (черепаха) - как справиться с этой ситуацией? - PullRequest
1 голос
/ 13 марта 2012

Я работаю над проектом в delphi 7 и Tortoise svn, проект является своего рода инструментом опроса.мы сейчас начинаем разработку новой версии, которая будет myproject 1.8, и через 2 месяца мы начнем с myproject 2.0.

Примечание : мы унаследовали уже существующуюСВН.так что это не наш дизайн

Сценарий : у меня есть только одна папка в моем c:\, то есть c:\project\myproject\, мы стартап, поэтому мы не начали с проекта, мы началиобработка из myproject 1.5 .. но теперь myproject 1.5 код исчез и превратился в myproject 1.6 .. поэтому, когда мы начали с myproject 1.7, мы создали папку c:\project\myproject\NV1.6Code и скопировали весь код в эту папку и начали с myproject 1.7 ... теперь я понятия не имею, как поддерживать под-версии, такие как myproject 1.7.1, myproject 1.7.2 или `myproject 1.6.4, в нашем текущем состоянии.

Теперь мы только начинаем с myproject 1.8и мы не знаем, как начать с него в элементе управления Subversion, так как тогда myproject 2.0 также скоро придет.

Структура : Путь: C:\projects\myproject

КакВы можете видеть на рисунке .. каталог NV1.6code имеет код версии 1.6, и все внешние каталоги имеют версию 1.7 code ..

Не очень хорошая идея? я не понимаюэто будет хорошей идеей

AIM : Как мне исправить описанный выше беспорядок?Пожалуйста, помогите мне, как я могу наилучшим образом использовать черепаху SVN в моем случае, чтобы поддерживать версию

  1. myproject version 1.6 ( then the subversion like 1.6.1 , 1.6.2, 1.6.3)
  2. myproject version 1.7 ( then the subversion like 1.7.1 , 1.7.2, 1.7.3)
  3. myproject version 1.8 ( then the subversion like 1.8.1 , 1.8.2, 1.8.3)
  4. then the future version myproject version 2.0

Ответы [ 3 ]

3 голосов
/ 13 марта 2012

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

  • Постарайтесь уменьшить количество своих веток.(обычно 2 или 3 достаточно в вашем проекте)
  • Для каждой выпущенной версии создайте тег.
  • Избегайте большого количества ветвей в контроле исходного кода без надлежащих механизмов для объединения изменений.
  • Если для объединения ваших изменений потрачено слишком много времени по сравнению со временем разработки, значит, что-то не так со структурой ветвей.
  • Если вы решили создать ветку, не откладывайте объединениянасколько вы можете.Любая попытка объединить все изменения всех веток одновременно (слияния большого взрыва) должна быть запрещена.
  • Команда не должна создавать много ветвей без видимой причины.
  • Если в системе создана какая-либо ветка (правильная или неправильная), ее изменения должны быть объединены с ее родительской ветвью (есливозможно) когда работа закончится.
  • Члены команды не должны останавливать действия по разработке, когда выполняются ветвления, слияния или построения новых базовых линий.
  • НЕ используйте ветви для разделения членов команды разработчиков, вместо того, чтобы делить работуони выступают.

Посмотрите на этот ответ для получения дополнительной информации.

2 голосов
/ 13 марта 2012

Это можно сделать двумя способами: с помощью функции ветки или тега.

В целом, мне нравится использовать тег для указания точки релиза, и разработка продолжается относительно линейно (1.6 идет к 1.7, 1.7 к 1.8 и т. Д.)

Однако, если по какой-то причине, скажем, вы выпустили 1.6, а основная разработка пошла на 1.7, но вы хотите продолжать вносить небольшие изменения в 1.6 (например, 1.6.1, 1.6.2 и т. Д.), Может быть полезно создать филиал.

Также прекрасно использовать обе функции вместе.

0 голосов
/ 13 марта 2012
...