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
|
*
* Build a past revision from history:
- Working; now rebuild only up to a particular point.
- A generic test that can be applied to any test working directory
that all previous revisions can be successfully recreated.
* Ignore-file support: finalize design and then implement it.
* Command-line options: should be passed down as arguments to ``cmd``
functions.
- ``commit`` message should be an option, not an argument.
* Class representing a tree (or working directory or branch)
- Should this really be a class or is it better to just have a set
of global functions? What data is held in memory other than the
directory name?
- List status and inventory sorted by file name.
- Add/move/delete files.
* Store patches in a zip file?
* When building diffs, show only the relevant tail of the two
filenames in the index line.
* Store patch headers in XML? What parser/generator to use? Maybe
tupletree-format, or Zope xmlpickle, or ElementTree_?
.. _ElementTree: http://effbot.org/zone/element-index.htm
* Make immutable files (e.g. recorded patches) read-only after they're
written. This would be a good idea, except that it means people
need to use ``rm -rf`` to remove branches, which may be dangerous.
Guiding principles
------------------
* In the first instance, just cache everything; don't worry about
recreating them from simpler components. So keep a copy around of
all previous revisions, their inventory and manifest, etc.
* Start writing a test framework into which new development can fit.
* No need to handle move/rename or subdirectories yet.
* Do try to add assertions against invalid states.
* Keep it simple in interface and implementation.
.. Local variables:
.. mode: rst
.. End:
|