← 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-09 06:09:42 UTC
  • Revision ID: mbp@sourcefrog.net-20050509060942-d9c9efd7feed0894
- more indicators at top of test output
- tidy up remotebranch stuff

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
 
53
 
__ http://mail.python.org/pipermail/python-list/2001-April/037847.html
54
 
 
55
 
* 'bzr ignore' command that just adds a line to the .bzrignore file
56
 
  and makes it versioned.
57
 
 
58
 
* 'bzr help commands' should give a one-line summary of each command.
 
52
* ``bzr ignore`` command that just adds a line to the ``.bzrignore`` file
 
53
  and makes it versioned.  Fix this to break symlinks.
59
54
 
60
55
* Any useful sanity checks in 'bzr ignore'?  Perhaps give a warning if
61
56
  they try to add a single file which is already versioned, or if they
62
57
  add a pattern which already exists, or if it looks like they gave an
63
58
  unquoted glob.
64
59
 
 
60
__ http://mail.python.org/pipermail/python-list/2001-April/037847.html
 
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
 
65
90
Medium things
66
91
-------------
67
92
 
87
112
* Turn on stat cache code, and add optimization about avoiding
88
113
  dangerous cache entries.
89
114
 
90
 
* mv command?
 
115
* ``bzr mv`` that does either rename or move as in Unix.
91
116
 
92
117
* More efficient diff of only selected files.
93
118
 
133
158
 
134
159
  - perhaps a pattern that matches only directories or non-directories
135
160
 
136
 
* Expansion of $Id$ keywords within working files.  Perhaps do this in
137
 
  exports first as a simpler case because then we don't need to deal
138
 
  with removing the tags on the way back in.
139
 
 
140
161
* Consider using Python logging library as well as/instead of
141
162
  bzrlib.trace.
142
163
 
 
164
* Commands should give some progress indication by default.
 
165
 
 
166
  - But quieten this with ``--silent``.
 
167
 
143
168
* Change to using gettext message localization.
144
169
 
145
170
* Make a clearer separation between internal and external bzrlib
149
174
  Consider using ZopeInterface definitions for the external interface;
150
175
  I think these are already used in PyBaz.  They allow automatic
151
176
  checking of the interface but may be unfamiliar to general Python
152
 
  developers.
 
177
  developers, so I'm not really keen.
153
178
 
154
179
* Commands to dump out all command help into a manpage or HTML file or
155
180
  whatever.
156
181
 
 
182
* Handle symlinks in the working directory; at the very least it
 
183
  should be possible for them to be present and ignored/unknown
 
184
  without causing assertion failures. 
 
185
 
 
186
  Eventually symlinks should be versioned.
 
187
 
 
188
* Allow init in a subdirectory to create a nested repository, but only
 
189
  if the subdirectory is not already versioned.   Perhaps also require
 
190
  a ``--nested`` to protect against confusion.
 
191
 
 
192
* Branch names? 
 
193
 
 
194
* More test framework:
 
195
 
 
196
  - Class that describes the state of a working tree so we can just
 
197
    assert it's equal.
 
198
 
 
199
* There are too many methods on Branch() that really manipulate the
 
200
  WorkingTree.  They should be moved across.  
 
201
 
 
202
  Also there are some methods which are duplicated on Tree and
 
203
  Inventory objects, and it should be made more clear which ones are
 
204
  proxies and which ones behave differently, and how.
 
205
 
 
206
* Try using XSLT to add some formatting to REST-generated HTML.  Or
 
207
  maybe write a small Python program that specifies a header and foot
 
208
  for the pages and calls into the docutils libraries.
 
209
 
 
210
* --format=xml for log, status and other commands.
 
211
 
 
212
* Attempting to explicitly add a file that's already added should give
 
213
  a warning; however there should be no warning for directories (since
 
214
  we scan for new children) or files encountered in a directory that's
 
215
  being scanned.
 
216
 
 
217
* Better handling of possible collisions on case-losing filesystems;
 
218
  make sure a single file does not get added twice under different
 
219
  names.
 
220
 
 
221
* Clean up XML inventory:
 
222
 
 
223
  - Use nesting rather than parent_id pointers.
 
224
 
 
225
  - Hold the ElementTree in memory in the Inventory object and work
 
226
    directly on that, rather than converting into Python objects every
 
227
    time it is read in.  Probably still expose it through some kind of
 
228
    object interface though, but perhaps that should just be a proxy
 
229
    for the elements.
 
230
 
 
231
  - Less special cases for the root directory. 
 
232
 
 
233
* Perhaps inventories should remember the revision in which each file
 
234
  was last changed, as well as its current state?  This is a bit
 
235
  redundant but might often be interested to know.
 
236
 
157
237
 
158
238
Large things
159
239
------------
160
240
 
 
241
* Generate annotations from current file relative to previous
 
242
  annotations.
 
243
 
 
244
  - Is it necessary to store any kind of annotation where data was
 
245
    deleted?
 
246
 
 
247
* Update revfile_ format and make it active:
 
248
 
 
249
  - Texts should be identified by something keyed on the revision, not
 
250
    an individual text-id.  This is much more useful for annotate I
 
251
    think; we want to map back to the revision that last changed it.
 
252
 
 
253
  - Access revfile revisions through the Tree/Store classes.
 
254
 
 
255
  - Check them from check commands.
 
256
 
 
257
  - Store annotations.
 
258
 
 
259
.. _revfile: revfile.html
 
260
 
161
261
* Hooks for pre-commit, post-commit, etc.
162
262
 
163
263
  Consider the security implications; probably should not enable hooks
174
274
* GUI (maybe in Python GTK+?)
175
275
 
176
276
* C library interface
 
277
 
 
278
* Expansion of $Id$ keywords within working files.  Perhaps do this in
 
279
  exports first as a simpler case because then we don't need to deal
 
280
  with removing the tags on the way back in.
 
281
 
 
282
* ``bzr find``