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

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

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

Но с DVCS, который не имеет смысла

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

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

Ответы

Ответ 1

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

Если вы идете со всеми ветвями, являющимися родственными каталогами, это будет работать нормально.

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

Ответ 2

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

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

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

~/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 repo хранится на github.com
  • gitorious --- Git repo хранится на gitorious.org
  • git --- Git repo хранится где-то в другом месте
  • gitsvn --- Subversion repo клонируется с помощью git -svn хранится где-то еще
  • hgbit --- Mercurial repo хранится на bitbucket.org
  • hg.gcode --- Mercurial repo хранится в коде Google
  • hg --- Mercurial repo хранится в другом месте
  • svn.gcode --- Репрессия Subversion хранится в коде Google
  • svn.sforge --- Репозиция Subversion хранится на Sourceforge.net
  • svn.work ---- Репозиторий Subversion, хранящийся на нашей компании svn server
  • svn --- Резервная копия Subversion хранится где-то

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

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

fabric.github.bitprophet      # Bitprophet fabric project cloned from Github
fabric.github.myusername      # My fork of the fabric project from Github
virtualenv.hgbit.ianb         # Ianb 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, поэтому этот ответ скорее всего наклонён в этом направлении.