~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to TODO

  • Committer: Robert Collins
  • Date: 2005-10-08 08:45:42 UTC
  • Revision ID: robertc@robertcollins.net-20051008084542-48ea5a99756f970e
add rm alias to remove

Show diffs side-by-side

added added

removed removed

Lines of Context:
17
17
Small things
18
18
------------
19
19
 
20
 
* is_within_any is very very dodgy
 
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
* Fix tests so that import errors caused by modules don't produce false reports
 
28
  that the tests themselves don't exist.
 
29
 
 
30
* Fix tests so that one test failure doesn't prevent other tests from running
 
31
 
 
32
* print a message at the end of running the tests telling them that the
 
33
  test log and output exists but can be removed
 
34
 
 
35
* tests for running the commit editor, and fix problem of not passing in 
 
36
  multiple arguments
21
37
 
22
38
* Merging add of a new file clashing with an existing file doesn't
23
39
  work; add gets an error that it's already versioned and the merge
68
84
* ``bzr status DIR`` should give status on all files under that
69
85
  directory.
70
86
 
71
 
* ``bzr log DIR`` should give changes to any files within DIR.
 
87
* ``bzr log DIR`` should give changes to any files within DIR; at the
 
88
  moment it only lists things which modify the specific named file
 
89
  (and not its contents)
72
90
 
73
91
* ``bzr inventory -r REV`` and perhaps unify this with ``bzr ls``,
74
92
  giving options to display ids, types, etc.
156
174
* Reproducible performance benchmark to measure whether performance is 
157
175
  getting better or worse.
158
176
 
 
177
* ``bzr log -m foo`` should perhaps error if nothing matches?
 
178
 
 
179
* ``bzr diff -r 30 -r 40 foo.c`` or ``bzr diff -r30..40 foo.c``
 
180
 
 
181
  If diffing between two branches then we probably want two -r
 
182
  options, since the revisions don't form a range that can be
 
183
  evaluated on either one.
 
184
 
 
185
* bzr diff shouldn't diff binary files
 
186
 
 
187
* setup.py install when run from a bzr tree should freeze the tree
 
188
  revision-id into the installed bzr.
 
189
 
 
190
* bzr script should trap ImportError and perhaps give a better error
 
191
  message?
 
192
 
 
193
* revert after a merge should possibly remove all the BASE/THIS/OTHER
 
194
  files to get you back to where you were.
 
195
 
 
196
* files that are added and then deleted are still reported as added
 
197
 
 
198
* stores should raise KeyError, not IndexError
 
199
 
 
200
* merging from a remote branch seems to sometimes raise errors not
 
201
  present locally
 
202
 
 
203
* should be possible to give a related branch when pulling from a
 
204
  remote branch to make things faster
 
205
 
 
206
* sometimes gives "conflicting add" even when the contents are in fact
 
207
  the same???
 
208
 
 
209
* BZRDIR should be in branch.py not __init__.py.
 
210
 
 
211
* ``status `` should accept a -r option to show changes relative to a revision,
 
212
  or between revisions
159
213
 
160
214
Medium things
161
215
-------------
162
216
 
163
 
* Merge revert patch.
164
 
 
165
 
* ``bzr mv`` that does either rename or move as in Unix.
 
217
* ~/.bzr.log is not written anymore for some reason.
 
218
 
 
219
* merge should add all revision and inventory XML to the local store.
 
220
 
 
221
* check should give a warning for revisions that are named in the
 
222
  chain but not actually present in the store.
 
223
 
 
224
* remove anything outside of the branch implementation that directly
 
225
  accesses the stores.
166
226
 
167
227
* More efficient diff of only selected files.  We should be able to
168
228
  just get the id for the selected files, look up their location and
182
242
 
183
243
* More test cases.
184
244
 
 
245
  - ``missing`` command
 
246
 
185
247
  - Selected-file commit
186
248
 
187
249
  - Impossible selected-file commit: adding things in non-versioned
201
263
 
202
264
  Given this we might be able to import patches at 1/second or better.
203
265
 
204
 
* Get branch over http.
205
 
 
206
 
* Pull pure updates over http.
207
 
 
208
266
* revfile compression.
209
267
 
210
 
* Split inventory into per-directory files.
 
268
* Split inventory into per-directory files?
211
269
 
212
270
* Fix ignore file parsing:
213
271
 
328
386
* Function to list a directory, saying in which revision each file was
329
387
  last modified.  Useful for web and gui interfaces, and slow to
330
388
  compute one file at a time.
331
 
 
332
 
* unittest is standard, but the results are kind of ugly; would be
333
 
  nice to make it cleaner.
 
389
  
 
390
  This will be done when we track file texts by referring to the
 
391
  version that created them. 
334
392
 
335
393
* Check locking is correct during merge-related operations.
336
394
 
345
403
 
346
404
* Track all merged-in revisions in a versioned add-only metafile.
347
405
 
 
406
* ``pull --clobber`` should discard any local changes not present
 
407
  remotely.  Not generally what you want, but possibly useful when
 
408
  you're just mirroring another branch and want to keep tracking it
 
409
  even when they e.g. uncommit or make similar non-forward movements.
 
410
  Also for push I suppose.  Clobber may not be the best name, maybe
 
411
  ``--destroy``?
 
412
 
 
413
* ``uncommit`` command that removes a revision from the end of the
 
414
  revision-history; just doing this is enough to remove the commit,
 
415
  and a new commit will automatically be made against the
 
416
  predecessor.  This can be repeated.
 
417
 
 
418
  It only makes sense to delete from the tail of history, not from the
 
419
  end.
 
420
 
 
421
  The revision, its inventory and texts remain floating in the store.
 
422
  We should perhaps add the revision to a list of removed-commits, so
 
423
  that it can be restored or at least accounted for when checking
 
424
  consistency.  This file would not be versioned, and probably should
 
425
  not propagate when branched.
 
426
 
 
427
  If we track merged revisions then we need to update this list too.
 
428
  If the list is stored in a weave it's easy (implicit): the version
 
429
  of the list can remain but it won't be referenced anymore.  It's
 
430
  probably best to just store this list in a weave in the first place
 
431
  and be done.
 
432
 
348
433
 
349
434
Large things
350
435
------------