21
27
* Import ElementTree update patch.
23
* Syntax should be "bzr export -r REV".
29
* Syntax should be ``bzr export -r REV``.
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.
37
41
* -r option should take a revision-id as well as a revno.
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.
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?)
45
* Tidier error for EPIPE: should be just "bzr: broken pipe" with no
46
other details because debugging information is rarely interesting.
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.
53
__ http://mail.python.org/pipermail/python-list/2001-April/037847.html
55
* 'bzr ignore' command that just adds a line to the .bzrignore file
56
and makes it versioned.
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.
57
* ``bzr help commands`` should give a one-line summary of each command.
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
64
__ http://mail.python.org/pipermail/python-list/2001-April/037847.html
66
* Read and write locks on branch while it's open.
68
* Separate read and write version checks?
70
* ``bzr status FILE...``
72
* Check all commands have decent help.
74
* Autogenerate argument/option help.
76
* ``bzr inventory -r REV`` and perhaps unify this with ``bzr ls``,
77
giving options to display ids, types, etc.
79
* Atomic file class that renames into place when it's closed.
134
151
- perhaps a pattern that matches only directories or non-directories
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.
140
153
* Consider using Python logging library as well as/instead of
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
165
developers, so I'm not really keen.
154
167
* Commands to dump out all command help into a manpage or HTML file or
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.
174
Eventually symlinks should be versioned.
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.
188
* Generate annotations from current file relative to previous
191
- Is it necessary to store any kind of annotation where data was
194
* Update revfile_ format and make it active:
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.
200
- Access revfile revisions through the Tree/Store classes.
202
- Check them from check commands.
206
.. _revfile: revfile.html
161
208
* Hooks for pre-commit, post-commit, etc.
163
210
Consider the security implications; probably should not enable hooks