← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to TODO

  • Committer: Martin Pool
  • Date: 2005-05-10 03:55:34 UTC
  • Revision ID: mbp@sourcefrog.net-20050510035534-643062e821052ac5
- Add fortune-cookie external plugin demonstration

Show diffs side-by-side

added added

removed removed

Lines of Context:
TODO
1
 
                                                 -*- indented-text -*-
 
1
.. -*- mode: indented-text; compile-command: "make -C doc" -*- 
 
2
 
 
3
 
 
4
*******************
 
5
Things to do in bzr
 
6
*******************
 
7
 
2
8
 
3
9
See also various low-level TODOs in the source code.  Try looking in
4
10
the list archive or on gmane.org for previous discussion of these
20
26
 
21
27
* Import ElementTree update patch.
22
28
 
23
 
* Syntax should be "bzr export -r REV".
24
 
 
25
 
* "cat -rREV FILE"
26
 
 
27
29
* Plugins that provide commands.  By just installing a file into some
28
 
  directory (e.g. /usr/share/bzr/plugins) it should be possible to
29
 
  create new top-level commands ("bzr frob").  Extensions can be
 
30
  directory (e.g. ``/usr/share/bzr/plugins``) it should be possible to
 
31
  create new top-level commands (``bzr frob``).  Extensions can be
30
32
  written in either Python (in which case they use the bzrlib API) or
31
33
  in a separate process (in sh, C, whatever).   It should be possible
32
34
  to get help for plugin commands.
36
38
 
37
39
* -r option should take a revision-id as well as a revno.
38
40
 
39
 
* "bzr info" could show space used by working tree, versioned files,
 
41
* ``bzr info`` could show space used by working tree, versioned files,
40
42
  unknown and ignored files. 
41
43
 
42
 
* "bzr info" should count only people with distinct email addresses as
 
44
* ``bzr info`` should count only people with distinct email addresses as
43
45
  different committers.  (Or perhaps only distinct userids?)
44
46
 
45
 
* Tidier error for EPIPE: should be just "bzr: broken pipe" with no
46
 
  other details because debugging information is rarely interesting.
47
 
 
48
 
* On Windows, command-line arguments should be glob-expanded__,
 
47
* On Windows, command-line arguments should be `glob-expanded`__,
49
48
  because the shell doesn't do this.  However, there are probably some
50
49
  commands where this shouldn't be done, such as 'bzr ignore', because
51
50
  we want to accept globs.
52
51
 
 
52
* ``bzr ignore`` command that just adds a line to the ``.bzrignore`` file
 
53
  and makes it versioned.  Fix this to break symlinks.
 
54
 
 
55
* Any useful sanity checks in 'bzr ignore'?  Perhaps give a warning if
 
56
  they try to add a single file which is already versioned, or if they
 
57
  add a pattern which already exists, or if it looks like they gave an
 
58
  unquoted glob.
 
59
 
53
60
__ http://mail.python.org/pipermail/python-list/2001-April/037847.html
54
61
 
 
62
* Separate read and write version checks?
 
63
 
 
64
* ``bzr status DIR`` should give status on all files under that
 
65
  directory.
 
66
 
 
67
* Check all commands have decent help.
 
68
 
 
69
* ``bzr inventory -r REV`` and perhaps unify this with ``bzr ls``,
 
70
  giving options to display ids, types, etc.
 
71
 
 
72
* Atomic file class that renames into place when it's closed.
 
73
 
 
74
* Don't abort if ``~/.bzr.log`` can't be used.
 
75
 
 
76
* Split BzrError into various more specific subclasses for different
 
77
  errors people might want to catch.
 
78
 
 
79
* If the export destination ends in '.tar', '.tar.gz', etc then create
 
80
  a tarball instead of a directory.  (Need to actually make a
 
81
  temporary directory and then tar that up.)
 
82
 
 
83
  http://www.gelato.unsw.edu.au/archives/git/0504/2194.html
 
84
  
 
85
* testbzr should by default test the bzr binary in the same directory
 
86
  as the testbzr script, or take a path to it as a first parameter.
 
87
 
 
88
  Should show the version from bzr and the path name.
 
89
 
 
90
* RemoteBranch could maintain a cache either in memory or on disk.  We
 
91
  know more than an external cache might about which files are
 
92
  immutable and which can vary.  On the other hand, it's much simpler
 
93
  to just use an external proxy cache.
 
94
 
 
95
 
55
96
Medium things
56
97
-------------
57
98
 
 
99
* Change command functions into Command() objects, like in hct, and
 
100
  then the grammar can be described directly in there.  Since all
 
101
  option definitions are global we can define them just once and
 
102
  reference them from each command.
 
103
 
58
104
* Selective commit of only some files.
59
105
 
60
106
* Faster diff/status.  
70
116
* Turn on stat cache code, and add optimization about avoiding
71
117
  dangerous cache entries.
72
118
 
73
 
* mv command?
 
119
* ``bzr mv`` that does either rename or move as in Unix.
74
120
 
75
121
* More efficient diff of only selected files.
76
122
 
116
162
 
117
163
  - perhaps a pattern that matches only directories or non-directories
118
164
 
119
 
* Expansion of $Id$ keywords within working files.  Perhaps do this in
120
 
  exports first as a simpler case because then we don't need to deal
121
 
  with removing the tags on the way back in.
 
165
* Consider using Python logging library as well as/instead of
 
166
  bzrlib.trace.
 
167
 
 
168
* Commands should give some progress indication by default.
 
169
 
 
170
  - But quieten this with ``--silent``.
 
171
 
 
172
* Change to using gettext message localization.
 
173
 
 
174
* Make a clearer separation between internal and external bzrlib
 
175
  interfaces.  Make internal interfaces use protected names.  Write at
 
176
  least some documentation for those APIs, probably as docstrings.
 
177
 
 
178
  Consider using ZopeInterface definitions for the external interface;
 
179
  I think these are already used in PyBaz.  They allow automatic
 
180
  checking of the interface but may be unfamiliar to general Python
 
181
  developers, so I'm not really keen.
 
182
 
 
183
* Commands to dump out all command help into a manpage or HTML file or
 
184
  whatever.
 
185
 
 
186
* Handle symlinks in the working directory; at the very least it
 
187
  should be possible for them to be present and ignored/unknown
 
188
  without causing assertion failures. 
 
189
 
 
190
  Eventually symlinks should be versioned.
 
191
 
 
192
* Allow init in a subdirectory to create a nested repository, but only
 
193
  if the subdirectory is not already versioned.   Perhaps also require
 
194
  a ``--nested`` to protect against confusion.
 
195
 
 
196
* Branch names? 
 
197
 
 
198
* More test framework:
 
199
 
 
200
  - Class that describes the state of a working tree so we can just
 
201
    assert it's equal.
 
202
 
 
203
* There are too many methods on Branch() that really manipulate the
 
204
  WorkingTree.  They should be moved across.  
 
205
 
 
206
  Also there are some methods which are duplicated on Tree and
 
207
  Inventory objects, and it should be made more clear which ones are
 
208
  proxies and which ones behave differently, and how.
 
209
 
 
210
* Try using XSLT to add some formatting to REST-generated HTML.  Or
 
211
  maybe write a small Python program that specifies a header and foot
 
212
  for the pages and calls into the docutils libraries.
 
213
 
 
214
* --format=xml for log, status and other commands.
 
215
 
 
216
* Attempting to explicitly add a file that's already added should give
 
217
  a warning; however there should be no warning for directories (since
 
218
  we scan for new children) or files encountered in a directory that's
 
219
  being scanned.
 
220
 
 
221
* Better handling of possible collisions on case-losing filesystems;
 
222
  make sure a single file does not get added twice under different
 
223
  names.
 
224
 
 
225
* Clean up XML inventory:
 
226
 
 
227
  - Use nesting rather than parent_id pointers.
 
228
 
 
229
  - Hold the ElementTree in memory in the Inventory object and work
 
230
    directly on that, rather than converting into Python objects every
 
231
    time it is read in.  Probably still expose it through some kind of
 
232
    object interface though, but perhaps that should just be a proxy
 
233
    for the elements.
 
234
 
 
235
  - Less special cases for the root directory. 
 
236
 
 
237
* Perhaps inventories should remember the revision in which each file
 
238
  was last changed, as well as its current state?  This is a bit
 
239
  redundant but might often be interested to know.
122
240
 
123
241
 
124
242
Large things
125
243
------------
126
244
 
 
245
* Generate annotations from current file relative to previous
 
246
  annotations.
 
247
 
 
248
  - Is it necessary to store any kind of annotation where data was
 
249
    deleted?
 
250
 
 
251
* Update revfile_ format and make it active:
 
252
 
 
253
  - Texts should be identified by something keyed on the revision, not
 
254
    an individual text-id.  This is much more useful for annotate I
 
255
    think; we want to map back to the revision that last changed it.
 
256
 
 
257
  - Access revfile revisions through the Tree/Store classes.
 
258
 
 
259
  - Check them from check commands.
 
260
 
 
261
  - Store annotations.
 
262
 
 
263
.. _revfile: revfile.html
 
264
 
127
265
* Hooks for pre-commit, post-commit, etc.
128
266
 
129
267
  Consider the security implications; probably should not enable hooks
140
278
* GUI (maybe in Python GTK+?)
141
279
 
142
280
* C library interface
 
281
 
 
282
* Expansion of $Id$ keywords within working files.  Perhaps do this in
 
283
  exports first as a simpler case because then we don't need to deal
 
284
  with removing the tags on the way back in.
 
285
 
 
286
* ``bzr find``