Проекты в рамках проектов с помощью Мерзавца

Я использовал мерзавца для сшивания вместе моего собственного GitHub размещенный проект и внешняя библиотека UI, которой я хотел пользоваться. Библиотека размещается в репозитории подверсии на SourceForge.

Я использовал подмодуль мерзавца и мерзавца-svn, и он работал обоснованно хорошо. Оборотные стороны были:

1. Чтобы быть в курсе репозитория библиотеки, я должен был выполнить, новая фиксация для обновления мерзавца подмодуля хешируют "указатель". Это вызвано тем, что подмодули мерзавца, в отличие от svn:externals, прикрепляются к конкретному идентификатору фиксации. Это не может быть фактической оборотной стороной, если Вы на самом деле хотите прикрепить стабильную версию, я работал с кодом, который был WIP.

2. Начальное получение по запросу мерзавца repo с подмодулями требует дополнительного шага с "подмодулем мерзавца init". Это не проблема для Вас, но для других, использующих Ваш код, который они должны будут помнить или быть сказаны выполнить этот шаг перед компиляцией/выполнением/тестированием Ваш код.

3. При использовании командной строки, легко завинтить репозиторий с мерзавцем - добавляют. Это вызвано тем, что Вы вводите git add subm<tab> завершаться к git add submodule, но это автоматически заполняет к git add submodule/ - отметьте запаздывающую наклонную черту. Если Вы выполняете команду с запаздывающей наклонной чертой, то она бомбит подмодуль и добавляет все его содержавшие файлы вместо этого. Это смягчено при помощи мерзавца-gui, git add . или просто обучение самостоятельно для удаления наклонной черты (это произошло со мной достаточно раз, что я обучил меня удалять его),

4. Фиксации подмодулей могут испортить перебазу мерзавцев-i. Я забываю точные детали, но это особенно плохо, если у Вас есть "грязный" подмодуль, и Вы выполняете переосновное интерактивное. Обычно с грязным деревом Вы не можете повторно базироваться, но подмодули не проверяются. Наличие нескольких фиксаций подмодуля в переосновной группе также вызывает проблемы. Последний хеш подмодуля предан первому, выбирают Ваш список, и это довольно хитро для фиксации позже. Это может работаться вокруг с более осторожным рабочим процессом (т.е. тщательно решающий, когда сделать Ваши фиксации подмодуля...), но может быть ЛАВАШ.

Шаги для установки этого были чем-то вроде:

1. Выполненный git svn clone https://project.svn.sourceforge.net/svnroot/project/project/trunk
2. Продвиньте это как "реальный" проект мерзавца к, например, GitHub
3. Теперь в Вашем собственном репозитории мерзавца, выполненном git submodule init
4. git submodule add git://github.com/project subproject
5. Выставьте это также к Вашему собственному repo на этот раз.

Это - это, более или менее. У Вас будет новый каталог "подпроектом", который в Вашем случае был бы геоотображающейся библиотекой.

Каждый раз, когда необходимо обновить геоотображающийся код, Вы выполнили бы что-то как:

cd subproject
git svn rebase
git svn push  # this updates the git mirror of the subproject
cd ..
git add subproject # careful with the trailing slash!
git commit -m "update subproject"
git push # this pushes the commit that updates the subproject

Я не видел ко многим учебным руководствам на потоке операций подмодуля мерзавца, таким образом, я надеюсь, что это помогает Вам решить.

подмодуль мерзавца мог бы быть тем, что Вы ищете:

http://book.git-scm.com/5_submodules.html

http://git-scm.org/gitwiki/GitSubmoduleTutorial

Из того небольшого, что я прочитал о Externals , похоже, это порт SVN «внешние» для GIT.

Это решает некоторые проблемы с подмодулями GIT, включая автоматическое обновление до последней версии.

Хотя у меня нет опыта работы с внешними SVN или с этим проектом, для некоторых это может быть лучшим решением, чем для других опубликованных.

В качестве альтернативы, следующее программное обеспечение (похоже, его можно использовать с GitHub). Может быть, это еще один способ снять кожу с кошки: Коса ( Страница Softpedia )

Это зависит от того, над каким проектом вы работаете, и с какими инструментами, если они есть, нужно взаимодействовать ваш СКМ. Например, Rails часто использует Capistrano для развертывания, и Capistrano делает определенные предположения о том, как будет выглядеть ваша структура каталогов относительно корня вашего хранилища. В этом случае, если у вас есть несколько взаимосвязанных приложений rails, вам необходимо использовать субмодули. Каждое приложение получает свой собственный репозиторий, и тогда у вас есть большой репозиторий, который управляет каждым из независимых репозиториев как подмодулями.

Даже если у вас нет инструментов, которые делают подобные предположения, хороший дизайн репозитория требует, чтобы вы ломали вещи немного, если есть хоть малейшая вероятность того, что однажды вы захотите использовать подраздел большого проекта независимо, или повторно использовать какой-то большой фрагмент кода в каком-то независимом проекте.

Извлечение некоторого подраздела репозитория в качестве отдельного объекта при сохранении истории версий сложно в git, и поэтому хорошей идеей является планирование на будущее.

Как для вашего конкретного вопроса, честно говоря, я бы назвал это идеальным примером того, где пара подмодулей была бы идеальной. Что касается совместного использования сценариев, если по какой-то причине это проблема, которая оказывается проблематичной, вы всегда можете использовать символическую ссылку.