Работаете с Mercurial локально и SVN удаленно? - PullRequest
3 голосов
/ 06 октября 2011

На работе мы используем Subversion, но поскольку никто не понимает, как ветвить нашу «ветвление», необходимо скопировать всю кодовую базу и рассматривать ее как отдельный репозиторий - это означает, что любые изменения, которые мы вносим в ветку «patch», необходимо скопировать / вставлены в основную ветку разработки («ствол»), чтобы они были синхронизированы, и мы не можем использовать какие-либо встроенные инструменты слияния (мы вручную используем WinMerge или аналогичный, чтобы найти измененные строки). Никто не хочет тратить время на то, чтобы узнать, как использовать возможности ветвления SVN, и вместо этого поощрять использование этой стратегии в качестве альтернативы.

Поскольку я не могу убедить всех остальных заняться реальным ветвлением, я пытаюсь сделать что-то для себя, чтобы сделать слияния менее болезненными. Я уже давно хотел заглянуть в Mercurial (раньше я немного использовал Git на своем Mac; Windows7 на работе) в качестве оптовой замены SVN, если бы я мог получить бай-ин.

У меня такой вопрос: во-первых, будет ли трудно использовать Mercurial на моей локальной машине, если мне придется отправить изменения в два репозитория SVN? Локально я мог бы использовать ветвление, чтобы легко объединить код, сохранить SVN-репозитории иначе, было бы просто перенести ветку в код исправления, а ветку dev (после слияния, конечно) в ветку dev в SVN, верно

Во-вторых, прежде чем я представлю Mercurial, есть ли лучший способ сделать это? Я пытался рассказать своим коллегам об использовании ветвления SVN, но я получил ответ, что «это работает на данный момент», поскольку никто не хочет тратить время на изучение ветвления SVN, и, если честно, я никогда не использовал SVN разветвляюсь, так что я не уверен, насколько легко / сложно это использовать, и не хочу рисковать, пытаясь разветвляться и что-то испортить.

Ответы [ 2 ]

2 голосов
/ 06 октября 2011

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

Конечно, «не хочу рисковать, пытаясь что-то разветвить и испортить», это очень типично для SVN, и то, что Mercurial делает намного лучше; так как вы всегда работаете в локальном репозитории, экспериментировать и делать ошибки - это дешево, и вы можете просто сделать новый клон, если запутаетесь. Я определенно рекомендую Mercurial поверх SVN практически в любой ситуации, за исключением хранилищ, которые должны содержать большие объемы двоичных данных, таких как художественные хранилища.

Теперь что касается ваших вопросов,

В принципе, вы можете использовать один и тот же рабочий каталог для хранилища Mercurial и SVN. Возможно, вы захотите добавить .hg и .svn в SVN и фильтры игнорирования Mercurial, и, конечно же, изменения, которые вы вносите в Mercurial, автоматически не фиксируются в SVN. Однако может быть удобно использовать Mercurial в качестве блокнота для локальной разработки. Если у вас есть две проверки SVN, в которых вы хотите сделать это, вы действительно можете просто обмениваться данными между клонами Mercurial, вытягивая или толкая их от одного к другому.

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

Если ваши коллеги выбрали SVN и не могут беспокоиться о Mercurial, вам, вероятно, придется с этим смириться. Возможно, есть некоторое утешение в том, что в подобных ситуациях их много, я лично хотел бы прекратить использовать SVN раньше, чем позже, но, тем не менее, в моей предыдущей и нынешней компании я, к сожалению, застрял с этим. Хотя в моей нынешней компании они готовы изменить его в какой-то момент в будущем, и мы уже работаем с git для внешнего проекта.

Еще одна вещь, которую я, вероятно, должен упомянуть: есть такие инструменты, как расширение hgsubversion, которые позволяют вам работать с Mercurial поверх SVN, преобразовывая все коммиты в коммиты Mercurial. Я не очень рекомендую, хотя, особенно если вы начинающий пользователь Mercurial, фундаментальное несоответствие между SVN и Mercurial означает, что ветвление на самом деле невозможно, если вы хотите отодвинуть изменения, вам придется все время перебазировать и Вы можете легко потерять данные.

1 голос
/ 07 октября 2011

Примечание:

svn merge URL1 URL2

можно использовать даже для несвязанных URL-адресов ( разных репозиторий ). Слияние внутри одного репо - это просто соглашение и рабочий процесс

Было бы сложно использовать Mercurial на моей локальной машине, если бы мне пришлось выталкивать изменения в два SVN-репозитория?

Нет, всегда прозрачно

  • Repo1 для MainSVN тянуть MainSVN + тянуть Repo2 + объединять головы + толкать
  • MainSVN Repo2 для DevSVN (тянуть DevSVN + нажать DevSVN)

прежде чем я представлю Mercurial, есть ли лучший способ сделать это?

См. Мою стартовую заметку - вы можете по крайней мере попробовать нативное объединение SVN между репозиториями

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