← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to TODO

  • Committer: Martin Pool
  • Date: 2005-07-04 12:26:02 UTC
  • Revision ID: mbp@sourcefrog.net-20050704122602-69901910521e62c3
- check command checks that all inventory-ids are the same as in the revision.

Show diffs side-by-side

added added

removed removed

Lines of Context:
TODO
24
24
  requires patching difflib to get it exactly right, or otherwise
25
25
  calling out to GNU diff.
26
26
 
27
 
* Import ElementTree update patch.
28
 
 
29
 
* Plugins that provide commands.  By just installing a file into some
30
 
  directory (e.g. ``/usr/share/bzr/plugins``) it should be possible to
31
 
  create new top-level commands (``bzr frob``).  Extensions can be
32
 
  written in either Python (in which case they use the bzrlib API) or
33
 
  in a separate process (in sh, C, whatever).   It should be possible
34
 
  to get help for plugin commands.
35
 
 
36
 
* Smart rewrap text in help messages to fit in $COLUMNS (or equivalent
37
 
  on Windows)
38
 
 
39
27
* -r option should take a revision-id as well as a revno.
40
28
 
41
 
* ``bzr info`` could show space used by working tree, versioned files,
42
 
  unknown and ignored files. 
43
 
 
44
29
* ``bzr info`` should count only people with distinct email addresses as
45
30
  different committers.  (Or perhaps only distinct userids?)
46
31
 
66
51
 
67
52
* ``bzr log DIR`` should give changes to any files within DIR.
68
53
 
69
 
* Check all commands have decent help.
70
 
 
71
54
* ``bzr inventory -r REV`` and perhaps unify this with ``bzr ls``,
72
55
  giving options to display ids, types, etc.
73
56
 
103
86
 
104
87
* Statcache should possibly map all file paths to / separators
105
88
 
 
89
* quotefn doubles all backslashes on Windows; this is probably not the
 
90
  best thing to do.  What would be a better way to safely represent
 
91
  filenames?  Perhaps we could doublequote things containing spaces,
 
92
  on the principle that filenames containing quotes are unlikely?
 
93
  Nice for humans; less good for machine parsing.
 
94
 
 
95
* Patches should probably use only forward slashes, even on Windows,
 
96
  otherwise Unix patch can't apply them. (?) 
 
97
 
 
98
* Branch.update_revisions() inefficiently fetches revisions from the
 
99
  remote server twice; once to find out what text and inventory they
 
100
  need and then again to actually get the thing.  This is a bit
 
101
  inefficient. 
 
102
 
 
103
  One complicating factor here is that we don't really want to have
 
104
  revisions present in the revision-store until all their constituent
 
105
  parts are also stored.
 
106
 
 
107
  The basic problem is that RemoteBranch.get_revision() and similar
 
108
  methods return object, but what we really want is the raw XML, which
 
109
  can be popped into our own store.  That needs to be refactored.
 
110
 
 
111
* ``bzr status FOO`` where foo is ignored should say so.
 
112
 
 
113
* ``bzr mkdir A...`` should just create and add A.
 
114
 
 
115
* Guard against repeatedly merging any particular patch.
 
116
  
 
117
 
106
118
 
107
119
Medium things
108
120
-------------
279
291
* unittest is standard, but the results are kind of ugly; would be
280
292
  nice to make it cleaner.
281
293
 
 
294
* Check locking is correct during merge-related operations.
 
295
 
 
296
* Perhaps attempts to get locks should timeout after some period of
 
297
  time, or at least display a progress message.
 
298
 
 
299
* Split out upgrade functionality from check command into a separate
 
300
  ``bzr upgrade``.
 
301
 
 
302
* Don't pass around command classes but rather pass objects.  This'd
 
303
  make it cleaner to construct objects wrapping external commands.
 
304
 
 
305
* Track all merged-in revisions in a versioned add-only metafile.
 
306
 
282
307
 
283
308
Large things
284
309
------------