~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to TODO

  • Committer: Martin Pool
  • Date: 2005-09-01 06:32:52 UTC
  • Revision ID: mbp@sourcefrog.net-20050901063252-00fc761bf1076759
- make target to build emacs TAGS file

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