Repositories and data analysis projects Context:
I've recently adopted version control as part of my data analysis work (finally I may hear you saying: see my earlier question on SO). This prompted me to think more about repositories and the directory structure I use for my projects. 
My typical research work involves one or more studies (i.e., data that I have collected) which gets written up as one or more publications (journal articles, book chapters, presentations, reports, etc.).  Analyses and reports are typically produced using a combination of R, LaTeX, Sweave, textual data files and so on. I really like the idea of being able to upload a single self-contained repository that can be used to analyse data and reproduce a publication.
In particular, I've been thinking about publications, studies, data, and common code, and how these entities map on to repositories. For example, is it better to have a separate repository for each publication or is it better to have each publication as an individual folder within the larger repository. I'm evolving a few thoughts on this, but I was keen to hear other options.
Question:


*

*What strategies do people use to map studies, publications, and analyses onto repositories?

*When should related entities (e.g., publications, studies, etc.) be split into multiple repositories?

 A: Regarding your first question: 

What strategies do people use to map studies, publications, and analyses onto repositories?

One year ago or so, I decided to have one repository for each publication, presentation or semester/class. My typical directory looks like this:
.git
.gitignore
README.org
ana
dat
doc
org
The underlying idea is (hopefully) obvious: Each publication, presentation, class is an "autarchic entity" which I could easily share with others.
By the way, you are not the first to ask this question: One repository/multiple projects without getting mixed up?
However, I also started using git for managing projects which might result in some publications (the directory structure follows roughly John Myles White's ProjectTemplate, without using it, though). 
.git
.gitignore
README.org
ana
data
docs
graphs
lib
org
reports
tests
Regarding your second question:

When should related entities (e.g., publications, studies, etc.) be split into multiple repositories?

I cannot think of any reason to split a publication, conference etc. related repository into multiple repositories. But I would be interested in other opinions...
A: I keep a separate repository for each project, with a project being centered around a particular data set or question being addressed. The repo contains the data, code, and Sweave documents/plots that explain and express the results.
I maintain a separate repo for each discrete publication or presentation because


*

*A single project may result in multiple publications or presentations. Once a publication is out or you've given the presentation, you are essentially "done" with the contents of that repo so they don't need to be dragged around with the project.

*A output (publication/presentation/chapter) may contain data from more than one project.

*Not all of the results from a project will end up in a particular piece of output. 


Code that is reusable across projects gets its own repo, as well. If I come up with a new & discrete question using data that is already in one repo, I'll copy that data to a new repo.
If you want to be really strict about it, many version control systems offer the idea of "subprojects", but I've found that to be overkill.
