Как Вы организуете несколько репозиториев мерзавца, так, чтобы все они были сохранены вместе?
Создайте курсор для итерации по переменной. 1. Вы можете выбрать список таблиц. Таблицы SHOW ----> К переменной 2. Создать курсор http://www.mysqltutorial.org/mysql-cursor/ 3. Запустить курсор с помощью код, который вы хотите!
С наилучшими пожеланиями!
5 ответов
Я был бы сильно , отговаривают от помещения несвязанных данных в данном репозитории Мерзавца. Издержки создания новых репозиториев являются довольно низкими, и это функция , который позволяет сохранить различные происхождения абсолютно отдельными.
Борьба, что идея означает заканчиваться с излишне запутанной историей, которая представляет более трудное администрирование и - что еще более важно - инструменты "археологии", менее полезные из-за получающегося растворения. Кроме того, как Вы упомянули, Мерзавец предполагает, что "единица клонирования" является репозиторием, и практически должна сделать так из-за его распределенного характера.
Одно решение состоит в том, чтобы сохранить каждый проект/пакет/и т.д. как ее собственное пустой репозиторий (т.е. без рабочего дерева) под счастливой иерархией, как:
/repos/a.git
/repos/b.git
/repos/c.git
, Как только несколько соглашений были установлены, это становится тривиальным для применения административных операций (резервное копирование, упаковка, веб-публикации) к полной иерархии, которая выполняет роль, не совсем отличающуюся от "монолитных" репозиториев SVN. Работа с этими репозиториями также становится несколько подобной рабочим процессам SVN с дополнением, которое один может использовать локальные фиксации и ответвления:
svn checkout --> git clone
svn update --> git pull
svn commit --> git push
у Вас может быть несколько пультов ДУ в каждом рабочем клоне, для простоты синхронизации между несколькими сторонами:
$ cd ~/dev
$ git clone /repos/foo.git # or the one from github, ...
$ cd foo
$ git remote add github ...
$ git remote add memorystick ...
можно тогда выбрать/вытянуть из каждого из "источников", работы и фиксировать локально, и затем продвинуть ("копируют") к каждым из этих пультов ДУ, когда Вы готовы с чем-то как (примечание, как это продвигает тот же фиксации и история к каждым из пультов ДУ!):
$ for remote in origin github memorystick; do git push $remote; done
самый легкий способ повернуть существующий рабочий репозиторий ~/dev/foo в такой пустой репозиторий, вероятно:
$ cd ~/dev
$ git clone --bare foo /repos/foo.git
$ mv foo foo.old
$ git clone /repos/foo.git
, который главным образом эквивалентен svn import - но не бросает существующую, "локальную" историю далеко.
Примечание: подмодули являются механизмом для включения совместно использованный , имел отношение происхождения, таким образом, я действительно не буду считать их соответствующим инструментом для проблемы, Вы пытаетесь решить.
, я еще не попробовал вложенные репозитории мерзавца, потому что я не столкнулся с ситуацией, где я должен. Поскольку я читал на , #git мерзавец канала , кажется, запутывается вложением репозитории, т.е. Вы пробуете мерзавцу-init в репозитории мерзавца. Единственный способ управлять вложенной структурой мерзавца состоит в том, чтобы или использовать git-submodule или Android repo утилита.
Что касается той резервной ответственности, которую Вы описываете, я говорю делегат это... Для меня я обычно помещал репозиторий "источника" для каждого проекта в сетевом диске на работе, которая регулярно сохраняется IT-techs их предпочтительной стратегией резервного копирования. Это просто, и я не должен волноваться об этом.;)
Я хочу добавить к ответ Дэмиена , в котором он рекомендует:
$ for remote in origin github memorystick; do git push $remote; done
Вы можете настроить специальный пульт, чтобы он передавался всем отдельным реальным пультам с помощью 1 команды; Я нашел его по адресу http://marc.info/?l=git&m=116231242118202&w=2 :
Так и для «git push» (где он делает смысл толкать одни и те же ветки несколько раз), вы можете сделать что я делаю:
.git / config содержит:
[удаленное "все"] url = master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6 url = login.osdl.org:linux-2.6.gitи теперь
git push all masterпереместит ветку «master» в в оба
этих удаленных репозиториев.
Вы также можете сэкономить, введя URL-адреса дважды, используя в строительстве:
[url ""] insteadOf =
Мне также интересно узнать о предлагаемых способах решения этой проблемы, и я опишу текущую настройку, которую я использую (с SVN). В основном я создал репозиторий, который содержит иерархию мини-файловой системы, включая собственные каталоги bin и lib. В корне этого дерева находится скрипт, который настроит ваше окружение для добавления этих bin, lib и т.д... других каталогов в соответствующие переменные окружения. Таким образом, корневой каталог выглядит следующим образом:
./bin/ # prepended to $PATH
./lib/ # prepended to $LD_LIBRARY_PATH
./lib/python/ # prepended to $PYTHONPATH
./setup_env.bash # sets up the environment
Теперь внутри /bin и /lib находятся несколько проектов и соответствующие им библиотеки. Я знаю, что это не стандартный проект, но это очень легко для кого-то другого в моей группе, чтобы проверить репозиторий, запустить сценарий 'setup_env.bash' и иметь самые последние версии всех проектов локально в их проверке. Им не нужно беспокоиться об установке/обновлении /usr/bin или /usr/lib, и это позволяет иметь несколько проверок и очень локализованное окружение для каждой проверки. Кто-то также может просто удалить весь репозиторий и не беспокоиться о деинсталляции каких-либо программ.
Для нас это работает хорошо, и я не уверен, что мы будем это менять. Проблема в том, что в одном большом репозитории много проектов. Есть ли стандартный способ git/Hg/bzr для создания подобной среды и разделения проектов на собственные репозитории?
.Есть еще один метод для создания вложенных репозиториев git, но он не решает проблема, которая вам нужна. Тем не менее, для тех, кто ищет решение, я был:
В репозитории git верхнего уровня просто скройте папку в .gitignore, содержащую вложенный репозиторий git. Это упрощает создание двух отдельных (но вложенных!) Репозиториев git.