Перемещение от SVN до HG: ветвление и резервное копирование
Моя компания выполняет svn прямо сейчас, и мы очень знакомы с ним. Однако, потому что мы делаем большую параллельную разработку, слияние может стать очень сложным.. Мы играли с hg, и нам действительно нравится способность сделать быстрые и эффективные клоны на основе на функцию.
У нас есть два основных вопроса, которые мы хотели бы решить, прежде чем мы переместимся в hg:
- Ответвления для бывших svn пользователей я знаком с "4 способами перейти в Подвижном", как изложено в статье Steve Losh. Мы думаем, что должны "осуществить" ответвления, потому что я думаю, что команда разработчиков найдет это самым простым способом мигрировать от svn. Следовательно, я предполагаю, что мы должны следовать за "ветвлением с клонами" модель, что означает, что отдельные клоны для ответвлений сделаны на сервере. В то время как это означает, что каждый клон/ответвление должен быть сделан на сервере и опубликован отдельно, это не слишком много проблемы для нас, поскольку мы привыкли проверять ответвления svn, которые снижаются как отдельные копии. Я волнуюсь, однако, что слияние изменений и после истории может стать трудным между ответвлениями в этой модели.
- Резервное копирование, Если программисты в нашей команде делают локальные клоны из ответвления, как они копируют локальный клон? Мы привыкли видеть svn сообщения о фиксации как это на ответвлении функции "Временная фиксация: функция дб, еще не работающая". Я не вижу способ сделать это легко в hg.
Совет с благодарностью получен. Rory
4 ответа
Однако меня беспокоит, что слияние изменения и последующая история могут становится затруднительным между филиалами в эта модель.
Итак, вы решили, что хотите хранить ветки в отдельных клонах, и это не бесплатно. Но нетрудно установить конфигурационный файл на уровне репозитория, который будет использовать псевдонимы для всех клонов, чтобы упростить использование / извлечение.
Если программисты в нашей команде сделают локальные клоны ветки, как они делают резервную копию местный клон? Мы привыкли видеть svn фиксирует подобные сообщения на функциональная ветка «Промежуточная фиксация: db функция еще не работает ". Я не вижу способ сделать это легко в hg.
Это причина номер один для использования DVCS, потому что она идеально поддерживает этот вариант использования. Коммиты являются локальными, пока вы их не нажмете. Это означает, что каждый разработчик может создавать столько «промежуточных» коммитов, сколько считает нужным. НО это не «резервная копия» в первоначальном смысле, это скорее «точка сохранения» для отдельного разработчика. До сих пор вы загромождали свою историю промежуточными коммитами, которые были доступны всем разработчикам вашей команды. Используя ртутные очереди, вы можете легко «свернуть» все эти промежуточные коммиты вместе перед их отправкой, что приведет к чистой истории в вашем центральном репозитории.
Если реальное резервное копирование (в смысле: что произойдет, если эта машина разработчика загорится) вызывает беспокойство, ответ прост: просто дайте каждому разработчику частный репозиторий сервера, куда он может регулярно отправлять сообщения.
Предложение: также изучите git.
В любой распределенной системе контроля версий, такой как hg или git, ваша локальная копия репозитория содержит как рабочие файлы, так и локальный репозиторий. Это может быть все резервное копирование, которое вам нужно. Если вам нужно больше, просто скопируйте файлы (включая файлы репозитория в каталоге .hg или .git) в место хранения резервной копии.
Я не могу говорить о вашей проблеме миграции ветки svn. Ваше решение звучит нормально, но параллелизм ОЧЕНЬ ОЧЕНЬ ТРУДНО, и я недостаточно хорошо подумал о вашей ситуации, чтобы сказать об этом.
Но если предположить, что вы действительно создаете отдельный репозиторий на сервере для каждой «svn-ветки», то я считаю, что вы можете очень легко решить свою вторую проблему. Во-первых, следуйте совету Питера Лорона , копируя файлы для работы. Затем, когда разработчик готов совершить коммит в «серверный репозиторий нашей команды» *, он может сделать коммит, как «hg-branch»: в том же самом репозитории. Вы получите такие же коммиты, как «Промежуточная фиксация: функция db еще не работает», но их не будет в стволе, чтобы испортить сборку каждого.
Ключ ко всей этой работе и причина того, почему hg / git так хороши, заключается в том, что когда функция ДЕЙСТВИТЕЛЬНО ВЫПОЛНЕНА, вы объединяете эту "hg-branch" обратно в ствол в том же репозитории, и есть вероятность намного лучше, чем с SVN, что автоматическое слияние ПРОСТО РАБОТАЕТ.
Если вам нужно много параллельной разработки, вам нужно использовать распределенную систему контроля версий, ClearCase или Perforce. ClearCase и Perforce не делают распределенного контроля версий, но они обрабатывают слияния, возможно, лучше, чем большинство других инструментов.
Слияние в ClearCase сделано для параллельной разработки и работает чрезвычайно хорошо. Фактически, большинство разработчиков в ClearCase разрабатывают в своей собственной ветке, а затем сливают свои изменения в интеграционный поток, когда работа над ними завершена. Слой UCM поверх ClearCase просто автоматизирует это поведение.
Слияние в Perforce более приспособлено к тому, что они называют дивергентным ветвлением, но, похоже, оно нормально справляется с одновременной разработкой.
Subversion - хорошая система контроля версий. Я часто использую ее, и вы не можете побить цену, но давайте посмотрим правде в глаза, слияние в Subversion все еще очень, очень грубо по краям. Использование свойств для отслеживания слияния очень хакерское. Когда вы просматриваете журналы, вы видите множество изменений просто потому, что Subversion изменила свойство svn:merge, даже если файлы в основном не были затронуты. Кроме того, вы должны знать, когда использовать флаг --reintegrate.
Конечно, распределенные системы управления версиями прекрасно справляются с параллельной разработкой. Так они и были задуманы с самого начала.
Мой единственный вопрос - почему вы делаете так много параллельной разработки? За годы работы я обнаружил, что принуждение разработчиков к совместной работе над одним и тем же набором изменений просто работает лучше всего. Когда разработчики вынуждены работать над одним и тем же набором кода, они более тщательно подходят к разработке. Они берут меньшие кусочки, более осторожно относятся к изменениям и больше общаются друг с другом.
Когда я работал с разработчиками в ClearCase, и у каждого разработчика была своя ветка, я ходил и проверял, чтобы разработчики регулярно объединяли свои изменения. Гораздо проще программировать, когда никто, кроме вас, не меняет код. Разработчики просто делали всю свою работу в своей ветке, не получая изменений, внесенных другими разработчиками. У вас 20 разработчиков, и вы не видите никаких изменений в основной ветке. Затем, прямо перед поставкой, разработчики производили массовое слияние всех своих изменений. Начиналась веселая кутерьма.
Следующую неделю мы потратили на то, чтобы все вычистить и заставить все изменения разработчиков работать вместе. Отдел контроля качества был расстроен, потому что у них почти не было времени на тестирование. Нередко релиз отправлялся не протестированным. В конце концов, у нас были сроки, в которые мы должны были уложиться".
Существуют веские причины для параллельной разработки, но я обнаружил, что во многих случаях разработчики просят об этом, потому что это облегчает их работу. Им не нужно координировать свои изменения, потому что теперь это ваша работа. В конце концов, именно за это они платят вам большие деньги.
Ну, не совсем большие деньги, но вам платят больше, чем многим другим людям. Может быть, не разработчикам, но вы зарабатываете больше, чем другие люди в вашей компании, например, уборщик - если только он не состоит в профсоюзе. Ну, вы получаете опционы на акции.