~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to TODO

  • Committer: Martin Pool
  • Date: 2005-08-30 03:29:32 UTC
  • Revision ID: mbp@sourcefrog.net-20050830032932-1ad1c40cfacde866
- add a docstring for the placeholder plugin

- remove the checkperms shell plugin, which was in the wrong
  place anyhow

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
.. -*- mode: indented-text; compile-command: "make -C doc" -*- 
 
1
.. -*- mode: indented-text; compile-command: "make -C doc" -*-
2
2
 
3
3
 
4
4
*******************
17
17
Small things
18
18
------------
19
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
 
20
41
* Add of a file that was present in the base revision should put back
21
42
  the previous file-id.
22
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
 
23
48
* Handle diff of files which do not have a trailing newline; probably
24
49
  requires patching difflib to get it exactly right, or otherwise
25
50
  calling out to GNU diff.
26
51
 
27
 
* Import ElementTree update patch.
28
 
 
29
 
* Syntax should be ``bzr export -r REV``.
30
 
 
31
 
* Plugins that provide commands.  By just installing a file into some
32
 
  directory (e.g. ``/usr/share/bzr/plugins``) it should be possible to
33
 
  create new top-level commands (``bzr frob``).  Extensions can be
34
 
  written in either Python (in which case they use the bzrlib API) or
35
 
  in a separate process (in sh, C, whatever).   It should be possible
36
 
  to get help for plugin commands.
37
 
 
38
 
* Smart rewrap text in help messages to fit in $COLUMNS (or equivalent
39
 
  on Windows)
 
52
* Should be able to copy files between branches to preserve their
 
53
  file-id (and perhaps eventually parentage.)
40
54
 
41
55
* -r option should take a revision-id as well as a revno.
42
56
 
43
 
* ``bzr info`` could show space used by working tree, versioned files,
44
 
  unknown and ignored files. 
 
57
* allow ``bzr st -r 300`` to show a summary of changes since then.
45
58
 
46
59
* ``bzr info`` should count only people with distinct email addresses as
47
60
  different committers.  (Or perhaps only distinct userids?)
54
67
* ``bzr ignore`` command that just adds a line to the ``.bzrignore`` file
55
68
  and makes it versioned.  Fix this to break symlinks.
56
69
 
57
 
* ``bzr help commands`` should give a one-line summary of each command.
58
 
 
59
70
* Any useful sanity checks in 'bzr ignore'?  Perhaps give a warning if
60
71
  they try to add a single file which is already versioned, or if they
61
72
  add a pattern which already exists, or if it looks like they gave an
63
74
 
64
75
__ http://mail.python.org/pipermail/python-list/2001-April/037847.html
65
76
 
66
 
* Read and write locks on branch while it's open.
67
 
 
68
77
* Separate read and write version checks?
69
78
 
70
 
* ``bzr status FILE...``
71
 
 
72
 
* Check all commands have decent help.
73
 
 
74
 
* Autogenerate argument/option help.
 
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)
75
85
 
76
86
* ``bzr inventory -r REV`` and perhaps unify this with ``bzr ls``,
77
87
  giving options to display ids, types, etc.
78
88
 
79
 
* Atomic file class that renames into place when it's closed.
80
 
 
81
 
* Don't abort if ``~/.bzr.log`` can't be used.
82
 
 
 
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.
83
205
 
84
206
Medium things
85
207
-------------
86
208
 
87
 
* Display command grammar in help messages rather than hardcoding it.
88
 
 
89
 
* Change command functions into Command() objects, like in hct, and
90
 
  then the grammar can be described directly in there.  Since all
91
 
  option definitions are global we can define them just once and
92
 
  reference them from each command.
93
 
 
94
 
* Selective commit of only some files.
95
 
 
96
 
* Faster diff/status.  
97
 
 
98
 
  Status should be handled differently because it needs to report on
99
 
  deleted and unknown files.  diff only needs to deal with versioned
100
 
  files.
101
 
 
102
 
* Merge Aaron's merge code.
103
 
 
104
 
* Merge revert patch.
105
 
 
106
 
* Turn on stat cache code, and add optimization about avoiding
107
 
  dangerous cache entries.
108
 
 
109
 
* ``bzr mv`` that does either rename or move as in Unix.
110
 
 
111
 
* More efficient diff of only selected files.
 
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.
112
225
 
113
226
* Fix up Inventory objects to represent root object as an entry.
114
227
 
115
 
* Don't convert entire entry from 
 
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.
116
231
 
117
232
* Extract changes from one revision to the next to a text form
118
233
  suitable for transmission over email.
119
234
 
120
235
* More test cases.
121
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
 
122
244
* Write a reproducible benchmark, perhaps importing various kernel versions.
123
245
 
124
 
* Change test.sh from Bourne shell into something in pure Python so
125
 
  that it can be more portable.
126
 
 
127
246
* Directly import diffs!  It seems a bit redundant to need to rescan
128
247
  the directory to work out what files diff added/deleted/changed when
129
248
  all the information is there in the diff in the first place.
133
252
  At the very least we could run diffstat over the diff, or perhaps
134
253
  read the status output from patch.  Just knowing which files might
135
254
  be modified would be enough to guide the add and commit.
136
 
  
 
255
 
137
256
  Given this we might be able to import patches at 1/second or better.
138
257
 
139
 
* Get branch over http.
140
 
 
141
 
* Pull pure updates over http.
142
 
 
143
258
* revfile compression.
144
259
 
145
 
* Split inventory into per-directory files.
 
260
* Split inventory into per-directory files?
146
261
 
147
262
* Fix ignore file parsing:
148
263
 
175
290
 
176
291
* Handle symlinks in the working directory; at the very least it
177
292
  should be possible for them to be present and ignored/unknown
178
 
  without causing assertion failures. 
 
293
  without causing assertion failures.
179
294
 
180
295
  Eventually symlinks should be versioned.
181
296
 
183
298
  if the subdirectory is not already versioned.   Perhaps also require
184
299
  a ``--nested`` to protect against confusion.
185
300
 
186
 
* Branch names? 
187
 
 
188
 
 
 
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.
189
424
 
190
425
 
191
426
Large things
222
457
  files, and respecting selective commits.  Run the pre-commit check
223
458
  (e.g. compile and run test suite) in there.
224
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
 
225
481
* Web interface
226
482
 
227
483
* GUI (maybe in Python GTK+?)