~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to TODO

  • Committer: Martin Pool
  • Date: 2005-06-27 05:03:27 UTC
  • Revision ID: mbp@sourcefrog.net-20050627050327-026aa1d4693cf62a
- rsync upload/download plugins from John A Meinel

Show diffs side-by-side

added added

removed removed

Lines of Context:
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
 
85
68
  immutable and which can vary.  On the other hand, it's much simpler
86
69
  to just use an external proxy cache.
87
70
 
 
71
  Perhaps ~/.bzr/http-cache.  Baz has a fairly simple cache under
 
72
  ~/.arch-cache, containing revision information encoded almost as a
 
73
  bunch of archives.  Perhaps we could simply store full paths.
 
74
 
88
75
* Maybe also store directories in the statcache so that we can quickly
89
76
  identify that they still exist.
90
77
 
 
78
* Diff should show timestamps; for files from the working directory we
 
79
  can use the file itself; for files from a revision we should use the
 
80
  commit time of the revision.
 
81
 
 
82
* Perhaps split command infrastructure from the actual command
 
83
  definitions.
 
84
 
 
85
* Cleaner support for negative boolean options like --no-recurse.
 
86
 
 
87
* Statcache should possibly map all file paths to / separators
 
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
 
91
116
 
92
117
Medium things
93
118
-------------
251
276
* XML attributes might have trouble with filenames containing \n and
252
277
  \r.  Do we really want to support this?  I think perhaps not.
253
278
 
 
279
* Remember execute bits, so that exports will work OK.
 
280
 
 
281
* Unify smart_add and plain Branch.add(); perhaps smart_add should
 
282
  just build a list of files to add and pass that to the regular add
 
283
  function.
 
284
 
 
285
* Function to list a directory, saying in which revision each file was
 
286
  last modified.  Useful for web and gui interfaces, and slow to
 
287
  compute one file at a time.
 
288
 
 
289
* unittest is standard, but the results are kind of ugly; would be
 
290
  nice to make it cleaner.
 
291
 
 
292
* Check locking is correct during merge-related operations.
 
293
 
 
294
* Perhaps attempts to get locks should timeout after some period of
 
295
  time, or at least display a progress message.
 
296
 
 
297
* Split out upgrade functionality from check command into a separate
 
298
  ``bzr upgrade``.
 
299
 
 
300
* Don't pass around command classes but rather pass objects.  This'd
 
301
  make it cleaner to construct objects wrapping external commands.
 
302
 
254
303
 
255
304
Large things
256
305
------------