1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
|
[[!meta title="(Un)entangling projects and repos"]]
[[!meta copyright="Copyright © 2023 Alexey Bochkarev"]]
[[!inline pages="internal(2023/info/unentangling-nav)" raw="yes"]]
<!-- Initially generated with emacsconf-publish-talk-page and then left alone for manual editing -->
<!-- You can manually edit this file to update the abstract, add links, etc. --->
# (Un)entangling projects and repos
Alexey Bochkarev (he/him) - <https://www.bochkarev.io>, @bochkarev@qoto.org (Mastodon)
[[!inline pages="internal(2023/info/unentangling-before)" raw="yes"]]
Emacs provides a few excellent tools for working on projects through
all their key stages. Orgmode is great for brainstorming, structuring
and maintaining TODO lists, tracking time, organizing notes, and
writing memos or reports. Many major modes help writing code, magit
makes version control almost frictionless, and projectile helps with
project management and navigation. However, I found a few situations
when I wanted to separate the concepts of "project" and "source
storage" (say, having a few version control repositories associated
with a single "generalized project").
In this talk, I would like:
1. to describe a specific example of such situation,
2. discuss a workflow aimed at managing such "generalized" projects
and present my solution, based on a very simple ELisp "glue" on top of
the functionality provided by package projectile.
For example, consider a research project (think: applied mathematics with
a heavy part of computational experiments). It might consist of:
- The \`\`paper'' draft: some sort of final report source, usually in
LaTeX format, or orgmode exported to PDF via LaTeX. Version controlled
by git.
- Numerical experiments: a separate folder, or even a separate git
repo. Contains the source code for numerical experiments and the
related technical documentation. Will be published along with the
paper.
- A collection of intermediate memos (notes) sent to collaborators.
- A collection of "raw" notes (lab journal), regarding what did I try
and especially what did NOT work and in which ways.
This setting raises a few problems that all boil down to the necessity
of having an easily accessible private notes file(s) associated with a
few repositories at the same time outside of these repos. This way one
can:
- Maintain more granular project structure and TODOs while still having
more concise TODO lists for the colleagues on a per-repository basis.
- Maintain (project-specific) private technical notes, and maybe a full
lab journal both describing the "big picture" of the project and
containing the technical information.
- Keep time tracking data private and outside of the source repositories,
- Capture thoughts and TODOs to a single place from across a few
specific repositories.
I propose to solve this problem by associating a single "notes folder"
and a main `.org` file to each repository using the standard mechanism
of directory-local variables on top of what is already provided by
projectile package.
[[!inline pages="internal(2023/info/unentangling-after)" raw="yes"]]
[[!inline pages="internal(2023/info/unentangling-nav)" raw="yes"]]
|
