Re: literate programming, development log -- ideas? (ominbus reply)

[Greg Minshall <minshall@umich.edu>]

Tim,

thanks for your comments.

> A lot depends on whether what you want is an org file which documents
> the current state of play or one which is more similar to a lab book
> which contains a more chronological type evolution of ideas and
> experiments. I often setup completely separate org 'projects' which will
> consist of multiple org files and will move things between different
> files as the project evolves. In some extreme cases, I may even have
> multiple git branches and will often use git tags to mark specific
> 'milestones'.
>
> How I decide whether to use a date tree with notes, branches, tags,
> archive sections/files, separate org files etc is typically determined
> by how likely I might be to want to review or go back through previous
> work/experiments/decisions. Working this out can take a bit of time and
> experimentation, but in general, I rarely need to checkout old versions
> or even open archive trees/files. I do have a journal file for each
> major project which has lots of ideas, random thoughts and even small
> experiments (with source blokcs) and I tend ot have a large 'reference'
> file which contains notes and links to external references and then a
> 'main' org file, which reflects the current state. 

my current curiosity is in how to integrate lab book, brain storming,
functionality into my projects.  it seems as if, in an extreme case, you
might possibly have
- a lab book sort of file (i.e., date order, minimal "going back and
  correcting entries")
- a journal file, unstructured, not-infrequently updated, notes, URLs,
  etc.
- the "main" org file -- that which "ships".
- an archive file (one per each of the other?)

for any given project, is the evolution from =foo.org= to this larger
number sort of organic, in the sense that you start with one file, then,
at some point, say, "okay, i need to put these bits in a new journal
file"?

and, trying to leverage the brain cells of others, have you tended to
settle on any sort of consistent naming scheme for the different files?
=-log=, =-notes=, etc.?

i suspect that if my brain were more git-shaped, i'd find the idea of
separate files easier.  i.e., my instinct is to think of each of these
files as having a version-path independent of the others.  rather than
the git-view, which is that the version-path is the commit-path, and
each commit includes the (mostly-temporally) related versions of each of
the files.  more [C-x v d], less [C-x v v].

again, thanks!  Greg