← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/work-order.txt

  • Committer: Vincent Ladeuil
  • Date: 2010-02-11 09:27:55 UTC
  • mfrom: (5017.3.46 test-servers)
  • mto: This revision was merged to the branch mainline in revision 5030.
  • Revision ID: v.ladeuil+lp@free.fr-20100211092755-3vvu4vbwiwjjte3s
Move tests servers from bzrlib.transport to bzrlib.tests.test_server

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/work-order.txt
1
 
* 
2
 
 
3
 
 
4
 
 
5
 
* Build a past revision from history:
6
 
 
7
 
  - Working; now rebuild only up to a particular point.
8
 
  
9
 
  - A generic test that can be applied to any test working directory
10
 
    that all previous revisions can be successfully recreated.
11
 
 
12
 
* Ignore-file support: finalize design and then implement it.
13
 
 
14
 
* Command-line options: should be passed down as arguments to ``cmd``
15
 
  functions. 
16
 
 
17
 
  - ``commit`` message should be an option, not an argument.
18
 
 
19
 
* Class representing a tree (or working directory or branch)
20
 
 
21
 
  - Should this really be a class or is it better to just have a set
22
 
    of global functions?  What data is held in memory other than the
23
 
    directory name?
24
 
 
25
 
  - List status and inventory sorted by file name.
26
 
 
27
 
  - Add/move/delete files.
28
 
 
29
 
* Store patches in a zip file?
30
 
 
31
 
* When building diffs, show only the relevant tail of the two
32
 
  filenames in the index line. 
33
 
 
34
 
* Store patch headers in XML?  What parser/generator to use?  Maybe
35
 
  tupletree-format, or Zope xmlpickle, or ElementTree_?
36
 
 
37
 
.. _ElementTree: http://effbot.org/zone/element-index.htm
38
 
 
39
 
* Make immutable files (e.g. recorded patches) read-only after they're
40
 
  written.  This would be a good idea, except that it means people
41
 
  need to use ``rm -rf`` to remove branches, which may be dangerous.
42
 
 
43
 
 
44
 
Guiding principles
45
 
------------------
46
 
 
47
 
* In the first instance, just cache everything; don't worry about
48
 
  recreating them from simpler components.  So keep a copy around of
49
 
  all previous revisions, their inventory and manifest, etc.
50
 
 
51
 
* Start writing a test framework into which new development can fit.
52
 
 
53
 
* No need to handle move/rename or subdirectories yet.
54
 
 
55
 
* Do try to add assertions against invalid states. 
56
 
 
57
 
* Keep it simple in interface and implementation.
58
 
 
59
 
 
60
 
 
61
 
 
62
 
.. Local variables:
63
 
.. mode: rst
64
 
.. End: