~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to TODO

  • Committer: Martin Pool
  • Date: 2005-07-18 13:12:43 UTC
  • Revision ID: mbp@sourcefrog.net-20050718131243-44532527fd065b31
- update convertinv to work with current weave code

Show diffs side-by-side

added added

removed removed

Lines of Context:
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
20
* Merging add of a new file clashing with an existing file doesn't
34
21
  work; add gets an error that it's already versioned and the merge
35
22
  aborts.
79
66
* ``bzr status DIR`` should give status on all files under that
80
67
  directory.
81
68
 
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)
 
69
* ``bzr log DIR`` should give changes to any files within DIR.
85
70
 
86
71
* ``bzr inventory -r REV`` and perhaps unify this with ``bzr ls``,
87
72
  giving options to display ids, types, etc.
164
149
 
165
150
  - and, of course, tests for all this
166
151
 
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.
 
152
* stat-cache update is too slow for some reason - why is Python making
 
153
  a lot of futex calls?
 
154
 
 
155
 
205
156
 
206
157
Medium things
207
158
-------------
208
159
 
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.
 
160
* Merge revert patch.
 
161
 
 
162
* ``bzr mv`` that does either rename or move as in Unix.
218
163
 
219
164
* More efficient diff of only selected files.  We should be able to
220
165
  just get the id for the selected files, look up their location and
234
179
 
235
180
* More test cases.
236
181
 
237
 
  - ``missing`` command
238
 
 
239
182
  - Selected-file commit
240
183
 
241
184
  - Impossible selected-file commit: adding things in non-versioned
255
198
 
256
199
  Given this we might be able to import patches at 1/second or better.
257
200
 
 
201
* Get branch over http.
 
202
 
 
203
* Pull pure updates over http.
 
204
 
258
205
* revfile compression.
259
206
 
260
 
* Split inventory into per-directory files?
 
207
* Split inventory into per-directory files.
261
208
 
262
209
* Fix ignore file parsing:
263
210
 
378
325
* Function to list a directory, saying in which revision each file was
379
326
  last modified.  Useful for web and gui interfaces, and slow to
380
327
  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. 
 
328
 
 
329
* unittest is standard, but the results are kind of ugly; would be
 
330
  nice to make it cleaner.
384
331
 
385
332
* Check locking is correct during merge-related operations.
386
333
 
395
342
 
396
343
* Track all merged-in revisions in a versioned add-only metafile.
397
344
 
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.
424
 
 
425
345
 
426
346
Large things
427
347
------------