~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:
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
 
64
49
* ``bzr status DIR`` should give status on all files under that
65
50
  directory.
66
51
 
67
 
* Check all commands have decent help.
 
52
* ``bzr log DIR`` should give changes to any files within DIR.
68
53
 
69
54
* ``bzr inventory -r REV`` and perhaps unify this with ``bzr ls``,
70
55
  giving options to display ids, types, etc.
71
56
 
72
 
* Atomic file class that renames into place when it's closed.
73
 
 
74
 
* Don't abort if ``~/.bzr.log`` can't be used.
75
 
 
76
57
* Split BzrError into various more specific subclasses for different
77
58
  errors people might want to catch.
78
59
 
82
63
 
83
64
  http://www.gelato.unsw.edu.au/archives/git/0504/2194.html
84
65
  
85
 
* testbzr should by default test the bzr binary in the same directory
86
 
  as the testbzr script, or take a path to it as a first parameter.
87
 
 
88
 
  Should show the version from bzr and the path name.
89
 
 
90
66
* RemoteBranch could maintain a cache either in memory or on disk.  We
91
67
  know more than an external cache might about which files are
92
68
  immutable and which can vary.  On the other hand, it's much simpler
93
69
  to just use an external proxy cache.
94
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
 
 
75
* Maybe also store directories in the statcache so that we can quickly
 
76
  identify that they still exist.
 
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
* Guard against repeatedly merging any particular patch.
 
116
  
 
117
 
95
118
 
96
119
Medium things
97
120
-------------
98
121
 
99
 
* Change command functions into Command() objects, like in hct, and
100
 
  then the grammar can be described directly in there.  Since all
101
 
  option definitions are global we can define them just once and
102
 
  reference them from each command.
103
 
 
104
 
* Selective commit of only some files.
105
 
 
106
 
* Faster diff/status.  
107
 
 
108
 
  Status should be handled differently because it needs to report on
109
 
  deleted and unknown files.  diff only needs to deal with versioned
110
 
  files.
111
 
 
112
 
* Merge Aaron's merge code.
113
 
 
114
122
* Merge revert patch.
115
123
 
116
124
* ``bzr mv`` that does either rename or move as in Unix.
117
125
 
118
 
* More efficient diff of only selected files.
 
126
* More efficient diff of only selected files.  We should be able to
 
127
  just get the id for the selected files, look up their location and
 
128
  diff just those files.  No need to traverse the entire inventories.
 
129
 
 
130
* ``bzr status DIR`` or ``bzr diff DIR`` should report on all changes
 
131
  under that directory.
119
132
 
120
133
* Fix up Inventory objects to represent root object as an entry.
121
134
 
122
 
* Don't convert entire entry from 
 
135
* Don't convert entire entry from ElementTree to an object when it is
 
136
  read in, but rather wait until the program actually wants to know
 
137
  about that node.
123
138
 
124
139
* Extract changes from one revision to the next to a text form
125
140
  suitable for transmission over email.
126
141
 
127
142
* More test cases.
128
143
 
 
144
  - Selected-file commit
 
145
 
 
146
  - Impossible selected-file commit: adding things in non-versioned
 
147
    directories, crossing renames, etc.
 
148
 
129
149
* Write a reproducible benchmark, perhaps importing various kernel versions.
130
150
 
131
 
* Change test.sh from Bourne shell into something in pure Python so
132
 
  that it can be more portable.
133
 
 
134
151
* Directly import diffs!  It seems a bit redundant to need to rescan
135
152
  the directory to work out what files diff added/deleted/changed when
136
153
  all the information is there in the diff in the first place.
246
263
  urlgrabber's docs say they are working on batched downloads; we
247
264
  could perhaps ride on that or just create a background thread (ew).
248
265
 
249
 
* Should be a signature at the top of the cache file.
250
 
 
251
266
* Paranoid mode where we never trust SHA-1 matches.
252
267
 
 
268
* Don't commit if there are no changes unless forced.
 
269
 
 
270
* --dry-run mode for commit?  (Or maybe just run with
 
271
  check-command=false?)
 
272
 
 
273
* Generally, be a bit more verbose unless --silent is specified.
 
274
 
 
275
* Function that finds all changes to files under a given directory;
 
276
  perhaps log should use this if a directory is given.
 
277
 
 
278
* XML attributes might have trouble with filenames containing \n and
 
279
  \r.  Do we really want to support this?  I think perhaps not.
 
280
 
 
281
* Remember execute bits, so that exports will work OK.
 
282
 
 
283
* Unify smart_add and plain Branch.add(); perhaps smart_add should
 
284
  just build a list of files to add and pass that to the regular add
 
285
  function.
 
286
 
 
287
* Function to list a directory, saying in which revision each file was
 
288
  last modified.  Useful for web and gui interfaces, and slow to
 
289
  compute one file at a time.
 
290
 
 
291
* unittest is standard, but the results are kind of ugly; would be
 
292
  nice to make it cleaner.
 
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
 
253
307
 
254
308
Large things
255
309
------------
285
339
  files, and respecting selective commits.  Run the pre-commit check
286
340
  (e.g. compile and run test suite) in there.
287
341
 
 
342
  Possibly this should be done by splitting the commit function into
 
343
  several parts (under a single interface).  It is already rather
 
344
  large.  Decomposition:
 
345
 
 
346
   - find tree modifications and prepare in-memory inventory
 
347
 
 
348
   - export that inventory to a temporary directory
 
349
 
 
350
   - run the test in that temporary directory
 
351
 
 
352
   - if that succeeded, continue to actually finish the commit
 
353
 
 
354
  What should be done with the text of modified files while this is
 
355
  underway?  I don't think we want to count on holding them in memory
 
356
  and we can't trust the working files to stay in one place so I
 
357
  suppose we need to move them into the text store, or otherwise into
 
358
  a temporary directory.
 
359
 
 
360
  If the commit does not actually complete, we would rather the
 
361
  content was not left behind in the stores.  
 
362
 
288
363
* Web interface
289
364
 
290
365
* GUI (maybe in Python GTK+?)