~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to TODO

  • Committer: Martin Pool
  • Date: 2005-05-03 07:48:35 UTC
  • Revision ID: mbp@sourcefrog.net-20050503074835-0133bd0c16440fcd
doc

Show diffs side-by-side

added added

removed removed

Lines of Context:
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"
 
29
* Syntax should be ``bzr export -r REV``.
26
30
 
27
31
* 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
 
32
  directory (e.g. ``/usr/share/bzr/plugins``) it should be possible to
 
33
  create new top-level commands (``bzr frob``).  Extensions can be
30
34
  written in either Python (in which case they use the bzrlib API) or
31
35
  in a separate process (in sh, C, whatever).   It should be possible
32
36
  to get help for plugin commands.
36
40
 
37
41
* -r option should take a revision-id as well as a revno.
38
42
 
39
 
* "bzr info" could show space used by working tree, versioned files,
 
43
* ``bzr info`` could show space used by working tree, versioned files,
40
44
  unknown and ignored files. 
41
45
 
42
 
* "bzr info" should count only people with distinct email addresses as
 
46
* ``bzr info`` should count only people with distinct email addresses as
43
47
  different committers.  (Or perhaps only distinct userids?)
44
48
 
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__,
 
49
* On Windows, command-line arguments should be `glob-expanded`__,
49
50
  because the shell doesn't do this.  However, there are probably some
50
51
  commands where this shouldn't be done, such as 'bzr ignore', because
51
52
  we want to accept globs.
52
53
 
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
* ``bzr ignore`` command that just adds a line to the ``.bzrignore`` file
 
55
  and makes it versioned.  Fix this to break symlinks.
 
56
 
 
57
* ``bzr help commands`` should give a one-line summary of each command.
59
58
 
60
59
* Any useful sanity checks in 'bzr ignore'?  Perhaps give a warning if
61
60
  they try to add a single file which is already versioned, or if they
62
61
  add a pattern which already exists, or if it looks like they gave an
63
62
  unquoted glob.
64
63
 
 
64
__ http://mail.python.org/pipermail/python-list/2001-April/037847.html
 
65
 
 
66
* Read and write locks on branch while it's open.
 
67
 
 
68
* Separate read and write version checks?
 
69
 
 
70
* ``bzr status FILE...``
 
71
 
 
72
* Check all commands have decent help.
 
73
 
 
74
* Autogenerate argument/option help.
 
75
 
 
76
* ``bzr inventory -r REV`` and perhaps unify this with ``bzr ls``,
 
77
  giving options to display ids, types, etc.
 
78
 
 
79
* Atomic file class that renames into place when it's closed.
 
80
 
 
81
 
65
82
Medium things
66
83
-------------
67
84
 
87
104
* Turn on stat cache code, and add optimization about avoiding
88
105
  dangerous cache entries.
89
106
 
90
 
* mv command?
 
107
* ``bzr mv`` that does either rename or move as in Unix.
91
108
 
92
109
* More efficient diff of only selected files.
93
110
 
133
150
 
134
151
  - perhaps a pattern that matches only directories or non-directories
135
152
 
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
153
* Consider using Python logging library as well as/instead of
141
154
  bzrlib.trace.
142
155
 
149
162
  Consider using ZopeInterface definitions for the external interface;
150
163
  I think these are already used in PyBaz.  They allow automatic
151
164
  checking of the interface but may be unfamiliar to general Python
152
 
  developers.
 
165
  developers, so I'm not really keen.
153
166
 
154
167
* Commands to dump out all command help into a manpage or HTML file or
155
168
  whatever.
156
169
 
 
170
* Handle symlinks in the working directory; at the very least it
 
171
  should be possible for them to be present and ignored/unknown
 
172
  without causing assertion failures. 
 
173
 
 
174
  Eventually symlinks should be versioned.
 
175
 
 
176
* Allow init in a subdirectory to create a nested repository, but only
 
177
  if the subdirectory is not already versioned.   Perhaps also require
 
178
  a ``--nested`` to protect against confusion.
 
179
 
 
180
* Branch names? 
 
181
 
 
182
 
 
183
 
157
184
 
158
185
Large things
159
186
------------
160
187
 
 
188
* Generate annotations from current file relative to previous
 
189
  annotations.
 
190
 
 
191
  - Is it necessary to store any kind of annotation where data was
 
192
    deleted?
 
193
 
 
194
* Update revfile_ format and make it active:
 
195
 
 
196
  - Texts should be identified by something keyed on the revision, not
 
197
    an individual text-id.  This is much more useful for annotate I
 
198
    think; we want to map back to the revision that last changed it.
 
199
 
 
200
  - Access revfile revisions through the Tree/Store classes.
 
201
 
 
202
  - Check them from check commands.
 
203
 
 
204
  - Store annotations.
 
205
 
 
206
.. _revfile: revfile.html
 
207
 
161
208
* Hooks for pre-commit, post-commit, etc.
162
209
 
163
210
  Consider the security implications; probably should not enable hooks
174
221
* GUI (maybe in Python GTK+?)
175
222
 
176
223
* C library interface
 
224
 
 
225
* Expansion of $Id$ keywords within working files.  Perhaps do this in
 
226
  exports first as a simpler case because then we don't need to deal
 
227
  with removing the tags on the way back in.
 
228
 
 
229
* ``bzr find``