Thomas L Holaday
Thomas L Holaday

Reputation: 13862

What directory structure makes sense for DVCS such as git?

What I am used to:


But with DVCS that doesn't make sense

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?

Upvotes: 11

Views: 3531

Answers (2)

Matthew Rankin
Matthew Rankin

Reputation: 461237

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.

Upvotes: 12

T.E.D.
T.E.D.

Reputation: 44814

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.

Upvotes: 8

Related Questions