Преобразование компании от SVN до Hg?
Я думаю, что проблему с журналированием можно решить с помощью регистрации в SQL, при условии , что вы можете разбить интересующие вас поля на разные столбцы. Вы не можете относиться к базе данных SQL как к текстовому полю и ожидать, что она будет лучше, это не так.
Как только вы получите все, что вас интересует, входя в столбцы, в которые вы хотите, гораздо проще отслеживать последовательные действия чего-либо, если вы сможете выделить это по столбцам. Например, если у вас был процесс «ввода», вы обычно регистрируете все, когда текст «процесс ввода» помещается в столбец «logtype» или «process». Затем, когда у вас возникают проблемы с «процессом ввода», оператор WHERE в этом столбце изолирует все процессы ввода.
5 ответов
Бесплатная книга доступна по адресу http://hgbook.red-bean.com/ и , опубликованная О'Рейли в 2009 году.
Начиная с версии 0.9.5 Mercurial поставляется с инструментом преобразования .
Я должен признать, что переключился на Git вместо Mercurial. Тем не менее, с помощью Git вы можете одновременно импортировать ветки, теги и ствол в один и тот же репозиторий. Git заботится обо всех и изящно хранит теги как теги, ветви как ветви и ствол как главную ветвь. Я уверен, что с Mercurial почти то же самое.
Я рекомендую вам как можно скорее перейти на Mercurial (или Git, или любую другую DVCS). Не продолжайте работать с двумя разными репозиториями. Когда я переключился, Я сохранял svn до тех пор, пока был достаточно уверен в Git (git-svn позволяет вам взаимодействовать от git к svn и наоборот). Затем я переключился и заблокировал репозитории SVN.
Было обсуждение (pro v con) распределенной Subversion, некоторые из них касаются элементов, которые SVN не делает так хорошо, как DVCS, и наоборот, но в ходе долгого обсуждения содержится много информации, полезной для всех, кто думает о переносе VCS компании.
Чтобы сразу перейти к хорошей публикации, попробуйте эту .
Если вы все же решили перейти на DVCS от SVN, возможно, вам стоит взглянуть на git-svn , который позволяет двунаправленные изменения между репозиторием svn и интерфейсами git. Он должен дать вам лучшее из обоих миров, но с использованием git вместо mercurial.
Пожалуйста, начните с Mercurial wiki . Там вы найдете заметную ссылку под названием Mercurial: The Definitive Guide , которая ссылается на hg book , как она называется. Вы, наверное, знаете svn book для Subversion - это эквивалент Mercurial (они даже размещены на одном сервере, но написаны разными авторами).
Далее на главной странице вики , вы найдете раздел для беженцев из других систем контроля версий. Есть ссылка на информацию для пользователей SVN и преобразование репозитория . Первый объясняет, что вы можете попробовать HgSubversion , если хотите выполнить двунаправленное преобразование между Subversion и Mercurial, а второй объясняет, как использовать расширение convert для (возможного инкрементного преобразования) ) Subversion -> Mercurial преобразование.
Вы уже нашли какие-либо из этих страниц? Если нет, расскажите, пожалуйста, как мы можем улучшить эти страницы, чтобы их было легче найти.
Я пару раз начинал преобразование из Subversion во что-то еще, один раз в Darcs, и теперь я играю с Git. Некоторое время назад я также довольно сильно перешел с CVS на Subversion.
Мой самый главный совет - не делайте все сразу. Выберите один нетривиальный, но небольшой проект и сконвертируйте его в первую очередь. Выделите разумный временной бюджет (час в день для каждого разработчика в течение первых двух недель не является необоснованным) для изучения системы и адаптации рабочего процесса. Примерно через месяц, когда у вас будет достаточный опыт работы с системой у нескольких разработчиков, вы можете подумать о преобразовании всего остального, если вы все еще чувствуете, что хотите пойти по этому пути. Когда вы это сделаете, убедитесь, что ваши разработчики, имеющие опыт работы с новой VCS, доступны для других, в идеале один должен работать в одной комнате со всеми, кто конвертируется.
О, да, и это предполагает, что вы уже поигрался с системой и построил «игрушечный» проект, используя ее. Впрочем, не слишком забавно: в нем должны участвовать как минимум три разработчика, несколько десятков файлов, сотни коммитов и должен использоваться рабочий процесс, аналогичный одному из ваших реальных проектов.
У меня был довольно большой репозиторий subversion, где каждая основная папка была модулем. Чтобы разделить его, я использовал следующее заклинание:
for i in *; do \
echo include "\"${i}\"" > /tmp/hgv.map; \
echo rename "\"${i}\"" . >> /tmp/hgv.map; \
hg convert --filemap /tmp/hgv.map /mnt/e/sqlwork/ "/mnt/h/work/${i}"; \
done
Оно получает все папки в текущем каталоге, генерирует карту файлов для подкоманды convert и преобразует каталог в hg-репозиторий. У меня не было никаких потерь истории и никаких других препятствий. Возможно, вы захотите взглянуть на расширение convert.