~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to TODO

  • Committer: Martin Pool
  • Date: 2005-07-11 03:12:34 UTC
  • Revision ID: mbp@sourcefrog.net-20050711031233-e5cc726bc78362e1
- fix typo

Show diffs side-by-side

added added

removed removed

Lines of Context:
17
17
Small things
18
18
------------
19
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
 
20
28
* Add of a file that was present in the base revision should put back
21
29
  the previous file-id.
22
30
 
24
32
  requires patching difflib to get it exactly right, or otherwise
25
33
  calling out to GNU diff.
26
34
 
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
35
* -r option should take a revision-id as well as a revno.
40
36
 
41
 
* ``bzr info`` could show space used by working tree, versioned files,
42
 
  unknown and ignored files. 
43
 
 
44
37
* ``bzr info`` should count only people with distinct email addresses as
45
38
  different committers.  (Or perhaps only distinct userids?)
46
39
 
66
59
 
67
60
* ``bzr log DIR`` should give changes to any files within DIR.
68
61
 
69
 
* Check all commands have decent help.
70
 
 
71
62
* ``bzr inventory -r REV`` and perhaps unify this with ``bzr ls``,
72
63
  giving options to display ids, types, etc.
73
64
 
124
115
  The basic problem is that RemoteBranch.get_revision() and similar
125
116
  methods return object, but what we really want is the raw XML, which
126
117
  can be popped into our own store.  That needs to be refactored.
 
118
 
 
119
* ``bzr status FOO`` where foo is ignored should say so.
 
120
 
 
121
* ``bzr mkdir A...`` should just create and add A.
 
122
 
 
123
* Guard against repeatedly merging any particular patch.
127
124
  
128
125
 
129
126
 
307
304
* Perhaps attempts to get locks should timeout after some period of
308
305
  time, or at least display a progress message.
309
306
 
 
307
* Split out upgrade functionality from check command into a separate
 
308
  ``bzr upgrade``.
 
309
 
 
310
* Don't pass around command classes but rather pass objects.  This'd
 
311
  make it cleaner to construct objects wrapping external commands.
 
312
 
 
313
* Track all merged-in revisions in a versioned add-only metafile.
 
314
 
310
315
 
311
316
Large things
312
317
------------