Разработчик работает над ветками с использованием SVN - PullRequest
1 голос
/ 25 января 2012

Мы только что перешли на SVN на работе, я настаивал на Mercurial, но это было отклонено на том основании, что никто из работающих здесь не слышал об этом.

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

Рабочий процесс, за который я борюсь, заключается в следующем:

  • Отделение ствола до какой-то приватной зоны.
  • Взлом, включая серьезные структурные изменения дерева
  • Hack
  • Hack
  • Объединить окончательный результат обратно в ствол.

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

Вот проблемы, с которыми я сталкиваюсь при выполнении этого рабочего процесса.

Наш репозиторий SVN имеет следующую структуру:

SVN
    \_ Project1
        \_ trunk
        \_ branches
        \_ tags
        \_ shelves
            \_ dev1
            \_ dev2
    \_ Project2
    . . .
    \_ Project3
    . . .

Проекты 2 и 3 имеют ту же структуру каталогов, что и Проект 1. Мы создали каталог полок в надежде на то, что разработчики смогут разветвляться и принимать на себя обязательства по оказанию помощи в разработке так же, как они используют Git или Mercurial. К сожалению, я не вижу способа, чтобы это могло работать с использованием SVN. Проблема в том, что после того, как что-то передается в SVN, другие пользователи не могут его игнорировать. Поэтому, если я создаю 2 или 3 ветки незавершенного производства в Project1-> shelves-> Dev1, то в следующий раз, когда кто-либо обновит либо Project 1, либо свою рабочую копию всего хранилища, это займет кровавое время, так как им приходится ждать каждую новую ветку быть загруженным. Обновление каждой новой ветки занимает около 5 минут, поэтому с полдюжины разработчиков, создающих 1 или более новых ветвей незавершенной работы каждый день, становится полностью неработоспособным.

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

Мое другое направление исследований заключалось в том, чтобы рассмотреть возможность использования Mercurial или Git для извлечения непосредственно из SVN (Mercurial, использующий hgsubversion, и Git, использующий git-svn). Оба этих подхода имеют сложности, возникающие в результате слияния ветвей разработки обратно в ветку, которую необходимо передать в SVN, но, несмотря на эту сложность, этот подход имеет некоторые перспективы. До этого я провел некоторое тестирование и обнаружил, что ни hgsubversion, ни git-svn не обращали никакого внимания на внешние файлы файла SVN, и я также натолкнулся на некоторую документацию, в которой предлагалось, что переименования / перемещения файлов в Git не будут фиксироваться в SVN должным образом История файла будет потеряна, что недопустимо.

Так что сейчас я смотрю на это.

  • Проверка моего источника с использованием SVN.
  • Копирование источника в новый каталог.
  • hg инициируйте новый каталог, чтобы получить рабочий каталог Mercurial, который я могу взломать.
  • Когда я закончу, используйте KDiff3 для сравнения моей окончательной рабочей копии Mercurial с исходным SVN-источником.
  • Используйте SVN перемещения / переименования / удаления, чтобы вручную исправить структурные изменения.
  • Копирование рабочей копии Mercurial через исходный код SVN и фиксация обратно в SVN.

Должен быть лучший способ. Пожалуйста, кто-нибудь, помогите мне найти это !!

1 Ответ

1 голос
/ 25 января 2012

Обычно вы не проверяете весь репозиторий таким образом - вы только проверяете ветку, над которой работаете (и используете svn switch для перемещения между ветвями)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...