« back to all changes in this revision
Viewing changes to TODO
- browse files at revision 394
- compare with another revision
- download diff
- download tarball
- view history from revision 394
- Committer: Martin Pool
- Date: 2005-05-08 03:33:57 UTC
- Revision ID: mbp@sourcefrog.net-20050508033357-3abe83faae4d1400
- Fix argument handling in export command
- Add test
Thanks to Aaron and Wilk
- Add test
Thanks to Aaron and Wilk
- files added:
- .rsyncexclude
- contrib
- contrib/bash
- contrib/zsh
- urlgrabber
- files removed:
- doc/faq.txt
- files modified:
- .bzrignore
added
removed
TODO
1
.. -*- mode: indented-text; compile-command: "make -C doc" -*-
2
3
4
*******************
5
Things to do in bzr
6
*******************
7
8
9
See also various low-level TODOs in the source code. Try looking in
10
the list archive or on gmane.org for previous discussion of these
11
issues.
12
13
These are classified by approximate size: an hour or less, a day or
14
less, and several days or more.
15
16
17
Small things
18
------------
19
20
* Add of a file that was present in the base revision should put back
21
the previous file-id.
22
23
* Handle diff of files which do not have a trailing newline; probably
24
requires patching difflib to get it exactly right, or otherwise
25
calling out to GNU diff.
26
27
* Import ElementTree update patch.
28
29
* Syntax should be ``bzr export -r REV``.
30
31
* Plugins that provide commands. By just installing a file into some
32
directory (e.g. ``/usr/share/bzr/plugins``) it should be possible to
33
create new top-level commands (``bzr frob``). Extensions can be
34
written in either Python (in which case they use the bzrlib API) or
35
in a separate process (in sh, C, whatever). It should be possible
36
to get help for plugin commands.
37
38
* Smart rewrap text in help messages to fit in $COLUMNS (or equivalent
39
on Windows)
40
41
* -r option should take a revision-id as well as a revno.
42
43
* ``bzr info`` could show space used by working tree, versioned files,
44
unknown and ignored files.
45
46
* ``bzr info`` should count only people with distinct email addresses as
47
different committers. (Or perhaps only distinct userids?)
48
49
* On Windows, command-line arguments should be `glob-expanded`__,
50
because the shell doesn't do this. However, there are probably some
51
commands where this shouldn't be done, such as 'bzr ignore', because
52
we want to accept globs.
53
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.
58
59
* Any useful sanity checks in 'bzr ignore'? Perhaps give a warning if
60
they try to add a single file which is already versioned, or if they
61
add a pattern which already exists, or if it looks like they gave an
62
unquoted glob.
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
* Don't abort if ``~/.bzr.log`` can't be used.
82
83
* Split BzrError into various more specific subclasses for different
84
errors people might want to catch.
85
86
* If the export destination ends in '.tar', '.tar.gz', etc then create
87
a tarball instead of a directory. (Need to actually make a
88
temporary directory and then tar that up.)
89
90
http://www.gelato.unsw.edu.au/archives/git/0504/2194.html
91
92
* testbzr should by default test the bzr binary in the same directory
93
as the testbzr script, or take a path to it as a first parameter.
94
95
Should show the version from bzr and the path name.
96
97
Medium things
98
-------------
99
100
* Display command grammar in help messages rather than hardcoding it.
101
102
* Change command functions into Command() objects, like in hct, and
103
then the grammar can be described directly in there. Since all
104
option definitions are global we can define them just once and
105
reference them from each command.
106
107
* Selective commit of only some files.
108
109
* Faster diff/status.
110
111
Status should be handled differently because it needs to report on
112
deleted and unknown files. diff only needs to deal with versioned
113
files.
114
115
* Merge Aaron's merge code.
116
117
* Merge revert patch.
118
119
* Turn on stat cache code, and add optimization about avoiding
120
dangerous cache entries.
121
122
* ``bzr mv`` that does either rename or move as in Unix.
123
124
* More efficient diff of only selected files.
125
126
* Fix up Inventory objects to represent root object as an entry.
127
128
* Don't convert entire entry from
129
130
* Extract changes from one revision to the next to a text form
131
suitable for transmission over email.
132
133
* More test cases.
134
135
* Write a reproducible benchmark, perhaps importing various kernel versions.
136
137
* Change test.sh from Bourne shell into something in pure Python so
138
that it can be more portable.
139
140
* Directly import diffs! It seems a bit redundant to need to rescan
141
the directory to work out what files diff added/deleted/changed when
142
all the information is there in the diff in the first place.
143
Getting the exact behaviour for added/deleted subdirectories etc
144
might be hard.
145
146
At the very least we could run diffstat over the diff, or perhaps
147
read the status output from patch. Just knowing which files might
148
be modified would be enough to guide the add and commit.
149
150
Given this we might be able to import patches at 1/second or better.
151
152
* Get branch over http.
153
154
* Pull pure updates over http.
155
156
* revfile compression.
157
158
* Split inventory into per-directory files.
159
160
* Fix ignore file parsing:
161
162
- fnmatch is not the same as unix patterns
163
164
- perhaps add extended globs from rsh/rsync
165
166
- perhaps a pattern that matches only directories or non-directories
167
168
* Consider using Python logging library as well as/instead of
169
bzrlib.trace.
170
171
* Commands should give some progress indication by default.
172
173
- But quieten this with ``--silent``.
174
175
* Change to using gettext message localization.
176
177
* Make a clearer separation between internal and external bzrlib
178
interfaces. Make internal interfaces use protected names. Write at
179
least some documentation for those APIs, probably as docstrings.
180
181
Consider using ZopeInterface definitions for the external interface;
182
I think these are already used in PyBaz. They allow automatic
183
checking of the interface but may be unfamiliar to general Python
184
developers, so I'm not really keen.
185
186
* Commands to dump out all command help into a manpage or HTML file or
187
whatever.
188
189
* Handle symlinks in the working directory; at the very least it
190
should be possible for them to be present and ignored/unknown
191
without causing assertion failures.
192
193
Eventually symlinks should be versioned.
194
195
* Allow init in a subdirectory to create a nested repository, but only
196
if the subdirectory is not already versioned. Perhaps also require
197
a ``--nested`` to protect against confusion.
198
199
* Branch names?
200
201
* More test framework:
202
203
- Class that describes the state of a working tree so we can just
204
assert it's equal.
205
206
* There are too many methods on Branch() that really manipulate the
207
WorkingTree. They should be moved across.
208
209
Also there are some methods which are duplicated on Tree and
210
Inventory objects, and it should be made more clear which ones are
211
proxies and which ones behave differently, and how.
212
213
* Try using XSLT to add some formatting to REST-generated HTML. Or
214
maybe write a small Python program that specifies a header and foot
215
for the pages and calls into the docutils libraries.
216
217
* --format=xml for log, status and other commands.
218
219
* Attempting to explicitly add a file that's already added should give
220
a warning; however there should be no warning for directories (since
221
we scan for new children) or files encountered in a directory that's
222
being scanned.
223
224
* Better handling of possible collisions on case-losing filesystems;
225
make sure a single file does not get added twice under different
226
names.
227
228
* Clean up XML inventory:
229
230
- Use nesting rather than parent_id pointers.
231
232
- Hold the ElementTree in memory in the Inventory object and work
233
directly on that, rather than converting into Python objects every
234
time it is read in. Probably still expose it through some kind of
235
object interface though, but perhaps that should just be a proxy
236
for the elements.
237
238
- Less special cases for the root directory.
239
240
* Perhaps inventories should remember the revision in which each file
241
was last changed, as well as its current state? This is a bit
242
redundant but might often be interested to know.
243
244
245
Large things
246
------------
247
248
* Generate annotations from current file relative to previous
249
annotations.
250
251
- Is it necessary to store any kind of annotation where data was
252
deleted?
253
254
* Update revfile_ format and make it active:
255
256
- Texts should be identified by something keyed on the revision, not
257
an individual text-id. This is much more useful for annotate I
258
think; we want to map back to the revision that last changed it.
259
260
- Access revfile revisions through the Tree/Store classes.
261
262
- Check them from check commands.
263
264
- Store annotations.
265
266
.. _revfile: revfile.html
267
268
* Hooks for pre-commit, post-commit, etc.
269
270
Consider the security implications; probably should not enable hooks
271
for remotely-fetched branches by default.
272
273
* Pre-commit check. If this hook is defined, it needs to be handled
274
specially: create a temporary directory containing the tree as it
275
will be after the commit. This means excluding any ignored/unknown
276
files, and respecting selective commits. Run the pre-commit check
277
(e.g. compile and run test suite) in there.
278
279
* Web interface
280
281
* GUI (maybe in Python GTK+?)
282
283
* C library interface
284
285
* Expansion of $Id$ keywords within working files. Perhaps do this in
286
exports first as a simpler case because then we don't need to deal
287
with removing the tags on the way back in.
288
289
* ``bzr find``
Loggerhead is a web-based interface for Breezy
Version: 2.0.1