← 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-02 04:24:33 UTC
  • Revision ID: mbp@sourcefrog.net-20050502042433-c825a7f7235f6b15
doc: notes on merge

Show diffs side-by-side

added added

removed removed

Lines of Context:
TODO
1
 
.. -*- mode: indented-text; compile-command: "make -C doc" -*- 
2
 
 
3
 
 
4
 
*******************
5
 
Things to do in bzr
6
 
*******************
7
 
 
 
1
                                                 -*- indented-text -*-
8
2
 
9
3
See also various low-level TODOs in the source code.  Try looking in
10
4
the list archive or on gmane.org for previous discussion of these
26
20
 
27
21
* Import ElementTree update patch.
28
22
 
 
23
* Syntax should be "bzr export -r REV".
 
24
 
 
25
* "cat -rREV FILE"
 
26
 
29
27
* Plugins that provide commands.  By just installing a file into some
30
 
  directory (e.g. ``/usr/share/bzr/plugins``) it should be possible to
31
 
  create new top-level commands (``bzr frob``).  Extensions can be
 
28
  directory (e.g. /usr/share/bzr/plugins) it should be possible to
 
29
  create new top-level commands ("bzr frob").  Extensions can be
32
30
  written in either Python (in which case they use the bzrlib API) or
33
31
  in a separate process (in sh, C, whatever).   It should be possible
34
32
  to get help for plugin commands.
38
36
 
39
37
* -r option should take a revision-id as well as a revno.
40
38
 
41
 
* ``bzr info`` could show space used by working tree, versioned files,
 
39
* "bzr info" could show space used by working tree, versioned files,
42
40
  unknown and ignored files. 
43
41
 
44
 
* ``bzr info`` should count only people with distinct email addresses as
 
42
* "bzr info" should count only people with distinct email addresses as
45
43
  different committers.  (Or perhaps only distinct userids?)
46
44
 
47
 
* On Windows, command-line arguments should be `glob-expanded`__,
 
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__,
48
49
  because the shell doesn't do this.  However, there are probably some
49
50
  commands where this shouldn't be done, such as 'bzr ignore', because
50
51
  we want to accept globs.
51
52
 
52
 
* ``bzr ignore`` command that just adds a line to the ``.bzrignore`` file
53
 
  and makes it versioned.  Fix this to break symlinks.
 
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.
54
59
 
55
60
* Any useful sanity checks in 'bzr ignore'?  Perhaps give a warning if
56
61
  they try to add a single file which is already versioned, or if they
57
62
  add a pattern which already exists, or if it looks like they gave an
58
63
  unquoted glob.
59
64
 
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
 
 
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
 
 
96
65
Medium things
97
66
-------------
98
67
 
 
68
* Display command grammar in help messages rather than hardcoding it.
 
69
 
99
70
* Change command functions into Command() objects, like in hct, and
100
71
  then the grammar can be described directly in there.  Since all
101
72
  option definitions are global we can define them just once and
113
84
 
114
85
* Merge revert patch.
115
86
 
116
 
* ``bzr mv`` that does either rename or move as in Unix.
 
87
* Turn on stat cache code, and add optimization about avoiding
 
88
  dangerous cache entries.
 
89
 
 
90
* mv command?
117
91
 
118
92
* More efficient diff of only selected files.
119
93
 
159
133
 
160
134
  - perhaps a pattern that matches only directories or non-directories
161
135
 
 
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
 
162
140
* Consider using Python logging library as well as/instead of
163
141
  bzrlib.trace.
164
142
 
165
 
* Commands should give some progress indication by default.
166
 
 
167
 
  - But quieten this with ``--silent``.
168
 
 
169
143
* Change to using gettext message localization.
170
144
 
171
145
* Make a clearer separation between internal and external bzrlib
175
149
  Consider using ZopeInterface definitions for the external interface;
176
150
  I think these are already used in PyBaz.  They allow automatic
177
151
  checking of the interface but may be unfamiliar to general Python
178
 
  developers, so I'm not really keen.
 
152
  developers.
179
153
 
180
154
* Commands to dump out all command help into a manpage or HTML file or
181
155
  whatever.
182
156
 
183
 
* Handle symlinks in the working directory; at the very least it
184
 
  should be possible for them to be present and ignored/unknown
185
 
  without causing assertion failures. 
186
 
 
187
 
  Eventually symlinks should be versioned.
188
 
 
189
 
* Allow init in a subdirectory to create a nested repository, but only
190
 
  if the subdirectory is not already versioned.   Perhaps also require
191
 
  a ``--nested`` to protect against confusion.
192
 
 
193
 
* Branch names? 
194
 
 
195
 
* More test framework:
196
 
 
197
 
  - Class that describes the state of a working tree so we can just
198
 
    assert it's equal.
199
 
 
200
 
* There are too many methods on Branch() that really manipulate the
201
 
  WorkingTree.  They should be moved across.  
202
 
 
203
 
  Also there are some methods which are duplicated on Tree and
204
 
  Inventory objects, and it should be made more clear which ones are
205
 
  proxies and which ones behave differently, and how.
206
 
 
207
 
* Try using XSLT to add some formatting to REST-generated HTML.  Or
208
 
  maybe write a small Python program that specifies a header and foot
209
 
  for the pages and calls into the docutils libraries.
210
 
 
211
 
* --format=xml for log, status and other commands.
212
 
 
213
 
* Attempting to explicitly add a file that's already added should give
214
 
  a warning; however there should be no warning for directories (since
215
 
  we scan for new children) or files encountered in a directory that's
216
 
  being scanned.
217
 
 
218
 
* Better handling of possible collisions on case-losing filesystems;
219
 
  make sure a single file does not get added twice under different
220
 
  names.
221
 
 
222
 
* Clean up XML inventory:
223
 
 
224
 
  - Use nesting rather than parent_id pointers.
225
 
 
226
 
  - Hold the ElementTree in memory in the Inventory object and work
227
 
    directly on that, rather than converting into Python objects every
228
 
    time it is read in.  Probably still exposoe it through some kind of
229
 
    object interface though, but perhaps that should just be a proxy
230
 
    for the elements.
231
 
 
232
 
  - Less special cases for the root directory. 
233
 
 
234
 
* Perhaps inventories should remember the revision in which each file
235
 
  was last changed, as well as its current state?  This is a bit
236
 
  redundant but might often be interested to know.
237
 
 
238
 
* stat cache should perhaps only stat files as necessary, rather than
239
 
  doing them all up-front.  On the other hand, that disallows the
240
 
  opimization of stating them in inode order.
241
 
 
242
 
* It'd be nice to pipeline multiple HTTP requests.  Often we can
243
 
  predict what will be wanted in future: all revisions, or all texts
244
 
  in a particular revision, etc.  
245
 
 
246
 
  urlgrabber's docs say they are working on batched downloads; we
247
 
  could perhaps ride on that or just create a background thread (ew).
248
 
 
249
 
* Should be a signature at the top of the cache file.
250
 
 
251
 
* Paranoid mode where we never trust SHA-1 matches.
252
 
 
253
157
 
254
158
Large things
255
159
------------
256
160
 
257
 
* Generate annotations from current file relative to previous
258
 
  annotations.
259
 
 
260
 
  - Is it necessary to store any kind of annotation where data was
261
 
    deleted?
262
 
 
263
 
* Update revfile_ format and make it active:
264
 
 
265
 
  - Texts should be identified by something keyed on the revision, not
266
 
    an individual text-id.  This is much more useful for annotate I
267
 
    think; we want to map back to the revision that last changed it.
268
 
 
269
 
  - Access revfile revisions through the Tree/Store classes.
270
 
 
271
 
  - Check them from check commands.
272
 
 
273
 
  - Store annotations.
274
 
 
275
 
.. _revfile: revfile.html
276
 
 
277
161
* Hooks for pre-commit, post-commit, etc.
278
162
 
279
163
  Consider the security implications; probably should not enable hooks
290
174
* GUI (maybe in Python GTK+?)
291
175
 
292
176
* C library interface
293
 
 
294
 
* Expansion of $Id$ keywords within working files.  Perhaps do this in
295
 
  exports first as a simpler case because then we don't need to deal
296
 
  with removing the tags on the way back in.
297
 
 
298
 
* ``bzr find``