Управление переходом от ClearCase к SVN

Question

Я отвечаю за переход с ClearCase на SVN на работе и ищу помощь в определении правильного рабочего процесса для команды.Мы работаем на ОЧЕНЬ большой базе кода с около 50 разработчиками, работающими на 3 разных сайтах.Я являюсь частью команды, посвященной репо.Мы не разработчики, но наша задача - объединить пакет разработок в следующих выпусках.И никто из нас не знаком с svn.

Наш текущий рабочий процесс на clearcase:

1. dev создает выделенный тип brtype (который будет создан для каждого элемента, который ониcheckout)
2. dev создает представление, указывающее на последнюю версию в «основной» ветке
3. dev dev, и проверяет его изменения в своей ветке
4. один раз в месяц, по возможности, командой (нас) создать вид brtype + сборка
5. На наш взгляд: объединить, скомпилировать, выпустить
6. Как только он будет выпущен, объединиться с основной веткой
7. repeat

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

Рабочий процесс SVN (предложение)

Я подумал об использовании 'команда patch '(мы работаем на Unix).

1. Dev проверяет (только для чтения) основной транк
2. коды.Создайте патч.Отправляет его сборочной команде.

3. Сборочная команда co.Примените патчи.Проверяет.

4. повтор

Мой вопрос - это правдоподобный рабочий процесс?Если это то, какие инструменты мы можем использовать для:

• доставки исправлений (некоторые исправления становятся частью выпуска через много месяцев после фактического времени разработки)
• конфликты слияния?

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

Answer 1

Вы можете увидеть (старую, но все еще актуальную) статью IBM о различиях между ClearCase и SVN

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

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

Итакваш исходный рабочий процесс еще не завершен, вам просто нужно быть осторожным при слиянии обратно в trunk.
См. Расширенное объединение (с последней версией SVN 1.7), где вам нужно svn merge --reintegrate.

Answer 2

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

Копии в SVN дешевы, потому что хранится только diff.Ваши патчи будут иметь такое же влияние на диск.Вы можете легко работать идентично рабочему процессу очистки.