Какая структура каталогов имеет смысл для DVCS, таких как git? - PullRequest
Новая
       7

Какая структура каталогов имеет смысл для DVCS, таких как git?

11 голосов
/ 31 марта 2009

К чему я привык:

  • Архивы на серверах (NY, IN, NC)
  • На моей машине для разработки:
    • Каталог с именем ~ / work
    • Подкаталоги с именами ~ / work / NY / devproject, ~ / work / NC / project и т. Д.
    • Нередко подкаталоги с именем ~ / work / NY / release / 1.3 / project, ~ / work / NY / test / 1.3b / project и т. Д.
    • Иногда каталоги с именем ~ / proxy / NY, ~ / прокси / NC и т. д., которые содержат одноразовый локальный кеш архивов, чтобы уменьшить сетевой трафик для чтения. Эти каталоги могут быть удалены в любое время.
  • Чистая сборка, которая удаляет ~ / work / ... и заполняет ее из архивов

Но с DVCS это не имеет смысла

  • Архивы находятся на моей машине для разработки, но из-за резервного копирования на удаленной машине находится почти клон.
  • Выполнение сборки с нуля означало бы удаление и повторное извлечение всего архива, что кажется дорогостоящим.
  • Похоже, у меня есть каталоги с именем ~ / git / git.git / git, в которых много gits.

Все ли люди занимаются разработкой в ​​~ / git? Если вам нужно работать с версиями dev, test, release и one-off-for-big-client, они находятся в ~ / git или они могут быть где-то еще в своих собственных деревьях? Куда идут сторонние компоненты? Это слишком велико для SO (мне нужно читать книгу) или на него можно ответить с помощью древовидной диаграммы ASCII?

Ответы [ 2 ]

12 голосов
/ 16 сентября 2009

Я согласен с ответом Т.Э. в том, что я предпочитаю хранить каждый проект в каталоге разработки. Однако, когда я нахожусь в терминале, просматривая список bash, мне нравится легко видеть три вещи:

  1. Какой тип репо это: Git, Mercurial или Subversion
  2. Где хранится псевдо-центральное репо - Github.com, Bitbucket.org, Google Code и т. Д.
  3. Кто владеет псевдоцентральным репо

Я обнаружил, что могу легко сделать это, используя следующие соглашения об именах для моих проектов: 

~/development/project.whatwhere.who

Поскольку при использовании Mercurial для клонирования локального проекта является обычным явлением, я добавляю один слой в структуру каталогов как: 

~/development/project.whatwhere.who/project/   # Initial clone from remote repo
~/development/project.whatwhere.who/project.local.blah_descriptor/  # Local hg clone

Соглашение whatwhere, которое я использую, выглядит следующим образом:

  • github --- репозиторий Git, хранящийся на github.com
  • gitorious --- Репозиторий Git хранится на gitorious.org
  • git --- Git-репо хранится где-то в другом месте
  • gitsvn --- Репозиторий Subversion, клонированный с помощью git-svn, хранящийся где-то еще
  • hgbit --- Репозиторий Mercurial, хранящийся на bitbucket.org
  • hg.gcode --- Mercurial репо хранится в коде Google
  • рт.ст. --- Mercurial репо хранится в другом месте
  • svn.gcode --- Репозиторий Subversion хранится в коде Google
  • svn.sforge --- Репозиторий Subversion, хранящийся на Sourceforge.net
  • svn.work ---- Репозиторий Subversion, хранящийся на svn-сервере нашей компании
  • svn --- Репозиторий Subversion хранится где-то

Соглашение who - это просто имя пользователя нужного человека.

Ниже приведены несколько примеров проектов, все они находятся в моем каталоге ~/development/: 

fabric.github.bitprophet      # Bitprophet's fabric project cloned from Github
fabric.github.myusername      # My fork of the fabric project from Github
virtualenv.hgbit.ianb         # Ianb's virtualenv project cloned from Bitbucket
growl.hg.gcode                # Growl project cloned from Google code
ledgersmb.svn.sforge          # LedgerSMB project checked out from Sourceforge
coldfire.gitsvn               # Coldfire Subversion project at work cloned using git-svn
coldfire.svn                  # Coldfire Subversion project at work checked out with svn

Чтобы упорядочить свои проекты, если вы получаете слишком много, вы можете добавить слой непосредственно под каталогом ~/development для организации. Например, вы можете иметь следующие каталоги: 

~/development/workprojects/
~/development/opensrcprojects/
~/development/personalprojects/

Примечание : Я обычно использую Git для DVCS, поэтому этот ответ, скорее всего, наклонен в этом направлении.

8 голосов
/ 31 марта 2009

Из-за того, как работает Git, вы действительно не хотите помещать рабочие каталоги для репозиториев (или веток) в каталог в рабочий каталог для другого репозитория. Он по-прежнему хотел бы поместить содержимое вашего дочернего каталога в репозиторий родителя.

Если вы используете все ветви как одноуровневые каталоги, это будет прекрасно работать.

То, что я обычно делаю (независимо от использования Git, cvs или (ick) SourceSafe), это наличие каталога разработки, и каждый проект, ветвь и т. Д. Должны быть там подкаталогом.

...