У меня есть удаленный репозиторий svn. Я хочу проверить его (с историей), а затем использовать в Visual Studio в качестве обычного репозитория. Через некоторое время я буду отправлять (фиксировать изменения) из локального репозитория в удаленный репозиторий (а также обновлять файлы, если таковые имеются).
Мне кажется, мне просто нужны две копии репозитория svn, и мне нужно их синхронизировать.
Как это сделать?
Это противоречит тому, что такое SVN. Похоже, что вам нравится DVCS, например Git или Mercurial, поэтому многие разработчики перешли к чему-то подобному.
Я бы использовал git; и используйте мост git-svn, чтобы иметь возможность связываться с сервером SVN.
Git хранит полную копию репозитория при клонировании из SVN (что означает, что начальный клон может занять много времени, так как он должен проверять каждую версию). Затем вы будете локально размещать свой репозиторий Git; и dcommit (push) обратно в ваш репозиторий SVN.
Я не знаю никаких чистых способов сделать это, используя только SVN. Типичный рабочий процесс может быть:
git svn clone http://yoursvnserver/svn --username vcsjones
#make some changes
git add -A
#stage your changes. add -A stages all changes;
#you can stage individial files too or use git add -i for interactive adding
git commit -m "My commit messages"
#repeat makes changes and commit as many times as you want
git svn dcommit
#commit all local commits back to the SVN repository.
Если вы магазин одного человека; держите свой репозиторий на флеш-накопителе USB (и просто убедитесь, что он подкрепляется каким-то образом, если вы его потеряете, он становится неисправным).
Как указывали другие ответы, у вас не может быть 2 SVN-репо с двунаправленной синхронизацией. Для пары SVN-SVN вы можете построить только одностороннюю синхронизацию RO SVN-зеркала.
Для локального репо, которое может обмениваться с центральным, вы должны использовать DVCS. Нет никакого способа сделать это с прямым SVN, не используя вспомогательный DVCS. Если вы не хотите Git, вы можете использовать Mercurial с hgsubversion, Bazaar... но в любом случае это дополнительный SCM.
Для сольной работы (если вы действительно должны работать таким образом), лучше было бы разветкиться на сервере. Просто не забудьте регулярно сливать сундук в свою ветку; это поможет вам избежать "слияния головной боли".
Как ответит vsjones, вы можете использовать git -svn для проверки репозитория Subversion, использовать его как локальный репозиторий Git, а затем опубликовать его обратно. Вы даже можете использовать Microsoft Git поставщик контроля источника, чтобы вы могли интегрировать Git с VisualStudio.
HOWEVER, я хотел бы спросить вас, почему вы хотите это сделать. Похоже, что вы можете быть тем, что мы в разговоре с языком CM, ползаем в вашу пещеру.
Сканирование в вашу пещеру означает, что вместо того, чтобы работать со всеми остальными, вы будете делать свою работу без присмотра. Вы хотите, чтобы ваш код был абсолютно идеальным. Вам нужен шедевр компьютерного кода. Затем вы откроете его в ничего не подозревающий мир, который будет поражен вашими навыками кодирования. Вы будете приветствовать гения и, возможно, даже получите возможность поговорить с девушкой.
Конечно, проблема в том, что кодирование всегда лучше всего работает, когда оно находится в открытом доступе. Кодовые обзоры относятся не только к завершенному коду. Это также для кода во время его написания. Прежде чем зайти слишком далеко по слепой тропе.
Еще одна проблема - это тенденция для разработчиков откусывать больше, чем они могут пережевывать. Если мне нужно проверить свою работу на том же сундуке, как и все остальные, я с большей вероятностью возьму меньше кусочков кода. (Да, я мог бы сделать каламбуру по байтам, но я стараюсь быть серьезным). Я сделаю изменения, возможно, добавлю несколько методов, испытаю и зафиксирую. Затем сделайте больше изменений, проверьте и зафиксируйте.
Я использую администратор ClearCase. В ClearCase каждый разработчик получает собственный поток разработки. Вы код в своем потоке, а затем объедините свою работу в потоке интеграции. (В принципе, каждый получил свою собственную ветку, и вы объединили свои изменения в багажник). В рамках моей работы я затрудняюсь разработчикам проверить их изменения. Я запускал отчеты, смотря в последний раз, когда разработчик доставил код. Мне постоянно приходилось обрабатывать проблемы слияния. Я чувствовал себя полицейским на ударе.
Тогда у меня была работа, где все использовали CVS. В CVS ветвление - это боль, поэтому все работали в одной ветки. Я не мог себе представить, как это будет работать. Как три десятка разработчиков работают на одной ветке? Но со временем я начал понимать, что не только каждый может работать в одной отрасли, но проблем меньше. Я больше не был полицейским, и вместо того, чтобы убедиться, что все разработчики соблюдали правила, я мог выполнять другие функции CM, которые у меня никогда не было. Мои отношения с разработчиками изменились. Я больше не был парнем, который пришел и сказал им, что делать. Вместо этого я был тем, кто мог помочь.
Итак, будьте осторожны, делая свою работу в своем собственном репозитории, а затем доставляете готовый продукт в свою команду. Если вы выполняете большую работу, которая потребует долгосрочного развития, которое может сломать сборку, когда вы это делаете, попросите свою собственную ветку функций в Subversion. Таким образом, каждый увидит, что вы делаете.
Это не означает, что нет законной причины использования Git svn. Мне лично нравится проверять мой код каждые несколько минут. Это дает мне возможность вернуть файл, как это было пять или десять минут, прежде чем я начал создавать беспорядок. Я все еще принимаю небольшие укусы, и я проверяю свой код, когда закончите. В нашем основном хранилище я усредню от 3 до 4 коммитов в день. Я тоже использую svn git, но не настолько, чтобы я мог залезть в свою пещеру, но у меня есть жизненная веревка, которую я могу использовать, чтобы вытащить меня из-за грязной ситуации кодирования.
Итак, взгляните на Git svn, но, пожалуйста, не используйте оправдание, что у вас есть собственный репозиторий, чтобы скрыться от остальной части вашей группы. Вы можете использовать MS Git Provider (или [поставщик SVN из AnkhSVN).
Существует способ клонирования SVN-репозитория на другой SVN-сайт со всей или частичной историей. Это так же просто, как выполнить команду ниже в bash.
clone-svn2svn.sh <source_svn_url> <destination_svn_url>
Я потратил довольно много времени на достижение этой цели и написал script, поэтому он автоматизирован и документирован для других. script использует git позади сцены, но он абстрагирует git от пользователя (если что-то не так, конечно).
GitHub: clone-svn2svn
Также есть инструкции по обновлению репозитория из источника после его клонирования. Вы можете найти их на странице GitHub. К сожалению, для этого я не писал script, и вам нужно заразиться руками с помощью командной строки git. Он также может быть автоматизирован.