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
