как создать локальную копию удаленного репозитория svn?
У меня есть удаленный репозиторий svn. Я хочу проверить его (с историей), а затем использовать в Visual Studio в качестве обычного репозитория. Через некоторое время я отправлю (зафиксирую изменения) из локального репозитория в удаленный репозиторий (а также обновлю файлы, если они есть).
похоже, мне просто нужны две копии репозитория svn, и мне нужна возможность их синхронизации.
Как это сделать?
4 ответов
это противоречит тому, что такое 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-mirror.
для локального РЕПО, которое можно обменять с центральным, вы необходимо использовать DVCS. Нет никакого способа сделать это с прямым SVN, не используя вспомогательный DVCS. Если вы не хотите Git, вы можете использовать Mercurial с Hgsubversion, Bazaar... но в любом случае это дополнительный SCM.
для Соло-работа (если вы действительно нужно работать таким образом) было бы лучше ветвиться на сервере. Просто не забывайте регулярно сливать ствол с веткой; это поможет вам избежать "головной боли слияния"."
Как ответил vsjones, вы можете использовать git-svn для проверки репозитория Subversion, использовать его в качестве локального репозитория Git, а затем опубликовать его. Вы даже можете использовать Поставщик Управления Версиями Microsoft Git чтобы вы могли интегрировать Git с VisualStudio.
Я хотел бы спросить вас, почему вы хотите это сделать. Похоже, вы можете быть тем, что мы на языке CM называем вползать в ваш Пещера!--7-->.
ползти в свою пещеру означает, что вместо того, чтобы работать со всеми, вы собираетесь делать свою работу без какого-либо контроля. Вы хотите, чтобы ваш код был абсолютно совершенным. Вам нужен шедевр компьютерного кода. Затем вы откроете его для ничего не подозревающего мира, который будет поражен вашими навыками кодирования. Тебя назовут гением, и, возможно, у тебя будет шанс поговорить с девушкой.
конечно, проблема в том, что кодирование всегда работает лучше всего, когда оно находится на виду. Проверки кода не только для завершенного кода. Это также для кода, пока он пишется. Пока вы не зашли слишком далеко по Слепой тропе.
еще одна проблема-тенденция разработчиков откусывать больше, чем они могут жевать. Если мне нужно проверить свою работу на том же багажнике, что и все остальные, я, скорее всего, возьму меньшие кусочки кода. (Да, я мог бы сделать каламбур на байт, но я пытаюсь быть серьезной). Я сделаю измените, возможно, добавьте несколько методов, протестируйте и зафиксируйте. Затем сделайте больше изменений, протестируйте и зафиксируйте.
Я использую, чтобы быть администратором ClearCase. В ClearCase каждый разработчик получает свой собственный поток разработки. Вы кодируете свой поток, а затем объединяете свою работу в поток интеграции. (В принципе, каждый получил свою собственную ветку, и вы объединили свои изменения в trunk). В рамках моей работы я бы побеспокоил разработчиков, чтобы проверить их изменения. Я побежал в последний раз, когда разработчик доставленный код. Мне постоянно приходилось решать проблемы слияния. Я чувствовал себя полицейским на побегушках.
тогда у меня была работа, где все использовали CVS. В CVS ветвление-это боль, поэтому все работали на одной ветке. Я не представляла, как это может сработать. Как три десятка разработчиков могут работать в одной отрасли? Но со временем я начал понимать, что не только все могут работать в одной отрасли, но и проблем меньше. Я больше не был патрульным, и вместо того, чтобы убедиться, что все разработчики следовали правилам, я мог делать другие функции CM, которые у меня никогда не было времени делать. Мои отношения с разработчиками изменилась. Я больше не был парнем, который приходил и говорил им, что делать. Вместо этого я был тем, кто мог помочь.
Итак, будьте осторожны, выполняя свою работу в собственном частном репозитории, а затем доставляя готовый продукт своей команде. Если вы делаете большую работу, которая потребует долгосрочного развития, что может ломать не строить пока вы это делаете, попросите свою собственную ветку функций в Subversion. Тогда все поймут, что ты задумал.
Это не значит, что нет законной причины для использования git svn. Лично мне нравится проверять свой код каждые несколько минут. Это дает мне возможность вернуть файл, как это было за пять или десять минут до того, как я начал беспорядок. Я все еще принимаю небольшие укусы, и я проверяю свой код, когда я закончу. Я буду в среднем от 3 до 4 коммитов в день в наш основной репозиторий. Я тоже используйте svn git, но не для того, чтобы я мог заползти в свою пещеру, а чтобы у меня была спасательная веревка, которую я могу использовать, чтобы вытащить меня из запутанной ситуации с кодированием.
Итак, взгляните на git svn, но, пожалуйста, не используйте оправдание, что у вас есть свой собственный репозиторий, чтобы спрятаться от остальной части вашей группы. Вы можете использовать поставщик MS Git (или [поставщик SVN из AnkhSVN).
клонировать SVN РЕПО на другой сайт SVN
существует способ клонирования репозитория SVN на другой сайт SVN со всей или частичной историей. Это так же просто, как запуск команды в bash.
clone-svn2svn.sh <source_svn_url> <destination_svn_url>
Я потратил довольно много времени на достижение этой цели и написал сценарий, чтобы он был автоматизирован и документирован для других. Сценарий использует git за сценой, но он абстрагирует git от пользователя (если, конечно, что-то не пойдет не так).
GitHub: клон-svn2svn
обновить репозиторий SVN
есть также инструкции о том, как обновить репозиторий из источника после его клонирования. Вы можете найти их на страница GitHub. К сожалению, я не написал сценарий для этого, и вам нужно испачкать руки командной строкой git. Его можно также автоматизировать.