~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to TODO

  • Committer: Martin Pool
  • Date: 2005-07-18 13:38:13 UTC
  • Revision ID: mbp@sourcefrog.net-20050718133813-4343f0cde39537de
- refactor member names in Weave code

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
For things to do in Bazaar development, see
2
 
 
3
 
https://bugs.launchpad.net/bzr/
4
 
https://blueprints.launchpad.net/bzr/
 
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
* Merging add of a new file clashing with an existing file doesn't
 
21
  work; add gets an error that it's already versioned and the merge
 
22
  aborts.
 
23
 
 
24
* Merge should ignore the destination's working directory, otherwise
 
25
  we get an error about the statcache when pulling from a remote
 
26
  branch.
 
27
 
 
28
* Add of a file that was present in the base revision should put back
 
29
  the previous file-id.
 
30
 
 
31
* Not sure I'm happy with needing to pass a root id to EmptyTree;
 
32
  comparing anything against an EmptyTree with no root should have the
 
33
  same effect(?)
 
34
 
 
35
* Handle diff of files which do not have a trailing newline; probably
 
36
  requires patching difflib to get it exactly right, or otherwise
 
37
  calling out to GNU diff.
 
38
 
 
39
* Should be able to copy files between branches to preserve their
 
40
  file-id (and perhaps eventually parentage.)
 
41
 
 
42
* -r option should take a revision-id as well as a revno.
 
43
 
 
44
* allow ``bzr st -r 300`` to show a summary of changes since then.
 
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
* Any useful sanity checks in 'bzr ignore'?  Perhaps give a warning if
 
58
  they try to add a single file which is already versioned, or if they
 
59
  add a pattern which already exists, or if it looks like they gave an
 
60
  unquoted glob.
 
61
 
 
62
__ http://mail.python.org/pipermail/python-list/2001-April/037847.html
 
63
 
 
64
* Separate read and write version checks?
 
65
 
 
66
* ``bzr status DIR`` should give status on all files under that
 
67
  directory.
 
68
 
 
69
* ``bzr log DIR`` should give changes to any files within DIR.
 
70
 
 
71
* ``bzr inventory -r REV`` and perhaps unify this with ``bzr ls``,
 
72
  giving options to display ids, types, etc.
 
73
 
 
74
* Split BzrError into various more specific subclasses for different
 
75
  errors people might want to catch.
 
76
 
 
77
* If the export destination ends in '.tar', '.tar.gz', etc then create
 
78
  a tarball instead of a directory.  (Need to actually make a
 
79
  temporary directory and then tar that up.)
 
80
 
 
81
  http://www.gelato.unsw.edu.au/archives/git/0504/2194.html
 
82
 
 
83
* RemoteBranch could maintain a cache either in memory or on disk.  We
 
84
  know more than an external cache might about which files are
 
85
  immutable and which can vary.  On the other hand, it's much simpler
 
86
  to just use an external proxy cache.
 
87
 
 
88
  Perhaps ~/.bzr/http-cache.  Baz has a fairly simple cache under
 
89
  ~/.arch-cache, containing revision information encoded almost as a
 
90
  bunch of archives.  Perhaps we could simply store full paths.
 
91
 
 
92
* Maybe also store directories in the statcache so that we can quickly
 
93
  identify that they still exist.
 
94
 
 
95
* Diff should show timestamps; for files from the working directory we
 
96
  can use the file itself; for files from a revision we should use the
 
97
  commit time of the revision.
 
98
 
 
99
* Perhaps split command infrastructure from the actual command
 
100
  definitions.
 
101
 
 
102
* Cleaner support for negative boolean options like --no-recurse.
 
103
 
 
104
* Statcache should possibly map all file paths to / separators
 
105
 
 
106
* quotefn doubles all backslashes on Windows; this is probably not the
 
107
  best thing to do.  What would be a better way to safely represent
 
108
  filenames?  Perhaps we could doublequote things containing spaces,
 
109
  on the principle that filenames containing quotes are unlikely?
 
110
  Nice for humans; less good for machine parsing.
 
111
 
 
112
* Patches should probably use only forward slashes, even on Windows,
 
113
  otherwise Unix patch can't apply them. (?)
 
114
 
 
115
* Branch.update_revisions() inefficiently fetches revisions from the
 
116
  remote server twice; once to find out what text and inventory they
 
117
  need and then again to actually get the thing.  This is a bit
 
118
  inefficient.
 
119
 
 
120
  One complicating factor here is that we don't really want to have
 
121
  revisions present in the revision-store until all their constituent
 
122
  parts are also stored.
 
123
 
 
124
  The basic problem is that RemoteBranch.get_revision() and similar
 
125
  methods return object, but what we really want is the raw XML, which
 
126
  can be popped into our own store.  That needs to be refactored.
 
127
 
 
128
* ``bzr status FOO`` where foo is ignored should say so.
 
129
 
 
130
* ``bzr mkdir A...`` should just create and add A.
 
131
 
 
132
* Guard against repeatedly merging any particular patch.
 
133
 
 
134
* More options for diff:
 
135
 
 
136
  - diff two revisions of the same tree
 
137
 
 
138
  - diff two different branches, optionally at different revisions
 
139
 
 
140
  - diff a particular file in another tree against the corresponding
 
141
    version in this tree (which should be the default if the second
 
142
    parameter is a tree root)
 
143
 
 
144
  - diff everything under a particular directory, in any of the above
 
145
    ways
 
146
 
 
147
  - diff two files inside the same tree, even if they have different
 
148
    ids
 
149
 
 
150
  - and, of course, tests for all this
 
151
 
 
152
* stat-cache update is too slow for some reason - why is Python making
 
153
  a lot of futex calls?
 
154
 
 
155
 
 
156
 
 
157
Medium things
 
158
-------------
 
159
 
 
160
* Merge revert patch.
 
161
 
 
162
* ``bzr mv`` that does either rename or move as in Unix.
 
163
 
 
164
* More efficient diff of only selected files.  We should be able to
 
165
  just get the id for the selected files, look up their location and
 
166
  diff just those files.  No need to traverse the entire inventories.
 
167
 
 
168
* ``bzr status DIR`` or ``bzr diff DIR`` should report on all changes
 
169
  under that directory.
 
170
 
 
171
* Fix up Inventory objects to represent root object as an entry.
 
172
 
 
173
* Don't convert entire entry from ElementTree to an object when it is
 
174
  read in, but rather wait until the program actually wants to know
 
175
  about that node.
 
176
 
 
177
* Extract changes from one revision to the next to a text form
 
178
  suitable for transmission over email.
 
179
 
 
180
* More test cases.
 
181
 
 
182
  - Selected-file commit
 
183
 
 
184
  - Impossible selected-file commit: adding things in non-versioned
 
185
    directories, crossing renames, etc.
 
186
 
 
187
* Write a reproducible benchmark, perhaps importing various kernel versions.
 
188
 
 
189
* Directly import diffs!  It seems a bit redundant to need to rescan
 
190
  the directory to work out what files diff added/deleted/changed when
 
191
  all the information is there in the diff in the first place.
 
192
  Getting the exact behaviour for added/deleted subdirectories etc
 
193
  might be hard.
 
194
 
 
195
  At the very least we could run diffstat over the diff, or perhaps
 
196
  read the status output from patch.  Just knowing which files might
 
197
  be modified would be enough to guide the add and commit.
 
198
 
 
199
  Given this we might be able to import patches at 1/second or better.
 
200
 
 
201
* Get branch over http.
 
202
 
 
203
* Pull pure updates over http.
 
204
 
 
205
* revfile compression.
 
206
 
 
207
* Split inventory into per-directory files.
 
208
 
 
209
* Fix ignore file parsing:
 
210
 
 
211
  - fnmatch is not the same as unix patterns
 
212
 
 
213
  - perhaps add extended globs from rsh/rsync
 
214
 
 
215
  - perhaps a pattern that matches only directories or non-directories
 
216
 
 
217
* Consider using Python logging library as well as/instead of
 
218
  bzrlib.trace.
 
219
 
 
220
* Commands should give some progress indication by default.
 
221
 
 
222
  - But quieten this with ``--silent``.
 
223
 
 
224
* Change to using gettext message localization.
 
225
 
 
226
* Make a clearer separation between internal and external bzrlib
 
227
  interfaces.  Make internal interfaces use protected names.  Write at
 
228
  least some documentation for those APIs, probably as docstrings.
 
229
 
 
230
  Consider using ZopeInterface definitions for the external interface;
 
231
  I think these are already used in PyBaz.  They allow automatic
 
232
  checking of the interface but may be unfamiliar to general Python
 
233
  developers, so I'm not really keen.
 
234
 
 
235
* Commands to dump out all command help into a manpage or HTML file or
 
236
  whatever.
 
237
 
 
238
* Handle symlinks in the working directory; at the very least it
 
239
  should be possible for them to be present and ignored/unknown
 
240
  without causing assertion failures.
 
241
 
 
242
  Eventually symlinks should be versioned.
 
243
 
 
244
* Allow init in a subdirectory to create a nested repository, but only
 
245
  if the subdirectory is not already versioned.   Perhaps also require
 
246
  a ``--nested`` to protect against confusion.
 
247
 
 
248
* Branch names?
 
249
 
 
250
* More test framework:
 
251
 
 
252
  - Class that describes the state of a working tree so we can just
 
253
    assert it's equal.
 
254
 
 
255
* There are too many methods on Branch() that really manipulate the
 
256
  WorkingTree.  They should be moved across.
 
257
 
 
258
  Also there are some methods which are duplicated on Tree and
 
259
  Inventory objects, and it should be made more clear which ones are
 
260
  proxies and which ones behave differently, and how.
 
261
 
 
262
* Try using XSLT to add some formatting to REST-generated HTML.  Or
 
263
  maybe write a small Python program that specifies a header and foot
 
264
  for the pages and calls into the docutils libraries.
 
265
 
 
266
* --format=xml for log, status and other commands.
 
267
 
 
268
* Attempting to explicitly add a file that's already added should give
 
269
  a warning; however there should be no warning for directories (since
 
270
  we scan for new children) or files encountered in a directory that's
 
271
  being scanned.
 
272
 
 
273
* Better handling of possible collisions on case-losing filesystems;
 
274
  make sure a single file does not get added twice under different
 
275
  names.
 
276
 
 
277
* Clean up XML inventory:
 
278
 
 
279
  - Use nesting rather than parent_id pointers.
 
280
 
 
281
  - Hold the ElementTree in memory in the Inventory object and work
 
282
    directly on that, rather than converting into Python objects every
 
283
    time it is read in.  Probably still exposoe it through some kind of
 
284
    object interface though, but perhaps that should just be a proxy
 
285
    for the elements.
 
286
 
 
287
  - Less special cases for the root directory.
 
288
 
 
289
* Perhaps inventories should remember the revision in which each file
 
290
  was last changed, as well as its current state?  This is a bit
 
291
  redundant but might often be interested to know.
 
292
 
 
293
* stat cache should perhaps only stat files as necessary, rather than
 
294
  doing them all up-front.  On the other hand, that disallows the
 
295
  opimization of stating them in inode order.
 
296
 
 
297
* It'd be nice to pipeline multiple HTTP requests.  Often we can
 
298
  predict what will be wanted in future: all revisions, or all texts
 
299
  in a particular revision, etc.
 
300
 
 
301
  urlgrabber's docs say they are working on batched downloads; we
 
302
  could perhaps ride on that or just create a background thread (ew).
 
303
 
 
304
* Paranoid mode where we never trust SHA-1 matches.
 
305
 
 
306
* Don't commit if there are no changes unless forced.
 
307
 
 
308
* --dry-run mode for commit?  (Or maybe just run with
 
309
  check-command=false?)
 
310
 
 
311
* Generally, be a bit more verbose unless --silent is specified.
 
312
 
 
313
* Function that finds all changes to files under a given directory;
 
314
  perhaps log should use this if a directory is given.
 
315
 
 
316
* XML attributes might have trouble with filenames containing \n and
 
317
  \r.  Do we really want to support this?  I think perhaps not.
 
318
 
 
319
* Remember execute bits, so that exports will work OK.
 
320
 
 
321
* Unify smart_add and plain Branch.add(); perhaps smart_add should
 
322
  just build a list of files to add and pass that to the regular add
 
323
  function.
 
324
 
 
325
* Function to list a directory, saying in which revision each file was
 
326
  last modified.  Useful for web and gui interfaces, and slow to
 
327
  compute one file at a time.
 
328
 
 
329
* unittest is standard, but the results are kind of ugly; would be
 
330
  nice to make it cleaner.
 
331
 
 
332
* Check locking is correct during merge-related operations.
 
333
 
 
334
* Perhaps attempts to get locks should timeout after some period of
 
335
  time, or at least display a progress message.
 
336
 
 
337
* Split out upgrade functionality from check command into a separate
 
338
  ``bzr upgrade``.
 
339
 
 
340
* Don't pass around command classes but rather pass objects.  This'd
 
341
  make it cleaner to construct objects wrapping external commands.
 
342
 
 
343
* Track all merged-in revisions in a versioned add-only metafile.
 
344
 
 
345
 
 
346
Large things
 
347
------------
 
348
 
 
349
* Generate annotations from current file relative to previous
 
350
  annotations.
 
351
 
 
352
  - Is it necessary to store any kind of annotation where data was
 
353
    deleted?
 
354
 
 
355
* Update revfile_ format and make it active:
 
356
 
 
357
  - Texts should be identified by something keyed on the revision, not
 
358
    an individual text-id.  This is much more useful for annotate I
 
359
    think; we want to map back to the revision that last changed it.
 
360
 
 
361
  - Access revfile revisions through the Tree/Store classes.
 
362
 
 
363
  - Check them from check commands.
 
364
 
 
365
  - Store annotations.
 
366
 
 
367
.. _revfile: revfile.html
 
368
 
 
369
* Hooks for pre-commit, post-commit, etc.
 
370
 
 
371
  Consider the security implications; probably should not enable hooks
 
372
  for remotely-fetched branches by default.
 
373
 
 
374
* Pre-commit check.  If this hook is defined, it needs to be handled
 
375
  specially: create a temporary directory containing the tree as it
 
376
  will be after the commit.  This means excluding any ignored/unknown
 
377
  files, and respecting selective commits.  Run the pre-commit check
 
378
  (e.g. compile and run test suite) in there.
 
379
 
 
380
  Possibly this should be done by splitting the commit function into
 
381
  several parts (under a single interface).  It is already rather
 
382
  large.  Decomposition:
 
383
 
 
384
   - find tree modifications and prepare in-memory inventory
 
385
 
 
386
   - export that inventory to a temporary directory
 
387
 
 
388
   - run the test in that temporary directory
 
389
 
 
390
   - if that succeeded, continue to actually finish the commit
 
391
 
 
392
  What should be done with the text of modified files while this is
 
393
  underway?  I don't think we want to count on holding them in memory
 
394
  and we can't trust the working files to stay in one place so I
 
395
  suppose we need to move them into the text store, or otherwise into
 
396
  a temporary directory.
 
397
 
 
398
  If the commit does not actually complete, we would rather the
 
399
  content was not left behind in the stores.
 
400
 
 
401
* Web interface
 
402
 
 
403
* GUI (maybe in Python GTK+?)
 
404
 
 
405
* C library interface
 
406
 
 
407
* Expansion of $Id$ keywords within working files.  Perhaps do this in
 
408
  exports first as a simpler case because then we don't need to deal
 
409
  with removing the tags on the way back in.
 
410
 
 
411
* ``bzr find``