What directory structure makes sense for DVCS such as git?

Question

What I am used to:

• Archives on the servers (NY, IN, NC)
• On my development machine:
  • A directory named ~/work
  • Subdirectories named ~/work/NY/devproject, ~/work/NC/project etc
  • Not infrequently, subdirectories named ~/work/NY/release/1.3/project, ~/work/NY/test/1.3b/project etc
  • Sometimes directories named ~/proxy/NY, ~/proxy/NC etc which contain a disposable local cache of the archives in order to reduce network traffic for reads. These directories can be deleted at any time.
• A scratch build that deletes ~/work/... and repopulates it from the archives

---

But with DVCS that doesn't make sense

• The archives are on my development machine, but a near-clone is on a remote machine for backup reasons.
• Doing a scratch build would mean deleting and re-pulling the whole archive, which seems costly.
• It looks like I have directories named ~/git/git.git/git which is a lot of gits.

Do people do all their development in ~/git? If you need to work with dev, test, release, and one-off-for-big-client versions, are these under ~/git, or can they be elsewhere in their own trees? Where do third-party components go? Is this too big for SO (do I need to read a book), or can it be answered with an ASCII tree diagram?

Answer 1

I agree with T.E.D.'s answer in that I prefer to keep each project in a development directory. However, when I'm in the terminal looking at a bash listing I like to easily see three things:

1. What type of repo is this --- Git, Mercurial, or Subversion
2. Where is the pseudo-central repo stored --- Github.com, Bitbucket.org, Google Code, etc.
3. Who owns the pseudo-central repo

I've found that I can easily do this by using the following naming convention for my projects:

~/development/project.whatwhere.who

Since it is common when using Mercurial to clone a local project, I add one layer to the directory structure as:

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

The whatwhere convention that I use is as follows:

• github --- Git repo stored on github.com
• gitorious --- Git repo stored on gitorious.org
• git --- Git repo stored somewhere elsewhere
• gitsvn --- Subversion repo cloned using git-svn stored somewhere else
• hgbit --- Mercurial repo stored on bitbucket.org
• hg.gcode --- Mercurial repo stored on Google code
• hg --- Mercurial repo stored elsewhere
• svn.gcode --- Subversion repo stored on Google code
• svn.sforge --- Subversion repo stored on Sourceforge.net
• svn.work ---- Subversion repo stored on our company's svn server
• svn --- Subversion repo stored somewhere

The who convention is simply the username of the desired person.

Below are a few project examples, all residing in my ~/development/ directory:

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

To help organize your projects if you get too many, you may want to add a layer immediately beneath the ~/development directory for organization. For example, you could have the following directories:

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

Note: I typically use Git for DVCS, so this answer is most likely slanted in that direction.

Answer 2

Because of the way Git works, you really don't want to place working directories for repositories (or branches) in a directory under the working directory for another repository. It would keep wanting to put the contents of your child directory into the parent's repository.

If you go with all branches being sibling directories, that would work just fine.

What I tend to do (regardless of using Git, cvs, or (ick) SourceSafe) is have a Development directory, and each project, branch, etc be a subdirectory in there.