~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to TODO

  • Committer: abentley
  • Date: 2005-10-14 03:50:50 UTC
  • mto: (1185.25.1)
  • mto: This revision was merged to the branch mainline in revision 1460.
  • Revision ID: abentley@lappy-20051014035050-d779472ccb599a51
semi-broke merge

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
 
20
27
* Fix tests so that import errors caused by modules don't produce false reports
21
28
  that the tests themselves don't exist.
22
29
 
52
59
 
53
60
* -r option should take a revision-id as well as a revno.
54
61
 
 
62
* allow ``bzr st -r 300`` to show a summary of changes since then.
 
63
 
55
64
* ``bzr info`` should count only people with distinct email addresses as
56
65
  different committers.  (Or perhaps only distinct userids?)
57
66
 
82
91
* ``bzr inventory -r REV`` and perhaps unify this with ``bzr ls``,
83
92
  giving options to display ids, types, etc.
84
93
 
 
94
* Split BzrError into various more specific subclasses for different
 
95
  errors people might want to catch.
 
96
 
 
97
* If the export destination ends in '.tar', '.tar.gz', etc then create
 
98
  a tarball instead of a directory.  (Need to actually make a
 
99
  temporary directory and then tar that up.)
 
100
 
 
101
  http://www.gelato.unsw.edu.au/archives/git/0504/2194.html
 
102
 
85
103
* RemoteBranch could maintain a cache either in memory or on disk.  We
86
104
  know more than an external cache might about which files are
87
105
  immutable and which can vary.  On the other hand, it's much simpler
127
145
  methods return object, but what we really want is the raw XML, which
128
146
  can be popped into our own store.  That needs to be refactored.
129
147
 
 
148
* ``bzr status FOO`` where foo is ignored should say so.
 
149
 
 
150
* ``bzr mkdir A...`` should just create and add A.
 
151
 
130
152
* Guard against repeatedly merging any particular patch.
131
153
 
132
154
* More options for diff:
147
169
 
148
170
  - and, of course, tests for all this
149
171
 
 
172
* ``bzr add`` with no arguments should probably be the same as ``bzr add .``
 
173
 
150
174
* Reproducible performance benchmark to measure whether performance is 
151
175
  getting better or worse.
152
176
 
184
208
 
185
209
* BZRDIR should be in branch.py not __init__.py.
186
210
 
 
211
* ``status `` should accept a -r option to show changes relative to a revision,
 
212
  or between revisions
 
213
 
187
214
Medium things
188
215
-------------
189
216
 
 
217
* ~/.bzr.log is not written anymore for some reason.
 
218
 
190
219
* merge should add all revision and inventory XML to the local store.
191
220
 
192
221
* check should give a warning for revisions that are named in the
199
228
  just get the id for the selected files, look up their location and
200
229
  diff just those files.  No need to traverse the entire inventories.
201
230
 
 
231
* ``bzr status DIR`` or ``bzr diff DIR`` should report on all changes
 
232
  under that directory.
 
233
 
202
234
* Fix up Inventory objects to represent root object as an entry.
203
235
 
204
236
* Don't convert entire entry from ElementTree to an object when it is
281
313
  - Class that describes the state of a working tree so we can just
282
314
    assert it's equal.
283
315
 
 
316
* There are too many methods on Branch() that really manipulate the
 
317
  WorkingTree.  They should be moved across.
 
318
 
 
319
  Also there are some methods which are duplicated on Tree and
 
320
  Inventory objects, and it should be made more clear which ones are
 
321
  proxies and which ones behave differently, and how.
 
322
 
284
323
* Try using XSLT to add some formatting to REST-generated HTML.  Or
285
324
  maybe write a small Python program that specifies a header and foot
286
325
  for the pages and calls into the docutils libraries.
302
341
 
303
342
  - Hold the ElementTree in memory in the Inventory object and work
304
343
    directly on that, rather than converting into Python objects every
305
 
    time it is read in.  Probably still expose it through some kind of
 
344
    time it is read in.  Probably still exposoe it through some kind of
306
345
    object interface though, but perhaps that should just be a proxy
307
346
    for the elements.
308
347
 
314
353
 
315
354
* stat cache should perhaps only stat files as necessary, rather than
316
355
  doing them all up-front.  On the other hand, that disallows the
317
 
  optimization of stating them in inode order.
 
356
  opimization of stating them in inode order.
318
357
 
319
358
* It'd be nice to pipeline multiple HTTP requests.  Often we can
320
359
  predict what will be wanted in future: all revisions, or all texts
325
364
 
326
365
* Paranoid mode where we never trust SHA-1 matches.
327
366
 
 
367
* Don't commit if there are no changes unless forced.
 
368
 
328
369
* --dry-run mode for commit?  (Or maybe just run with
329
370
  check-command=false?)
330
371
 
336
377
* XML attributes might have trouble with filenames containing \n and
337
378
  \r.  Do we really want to support this?  I think perhaps not.
338
379
 
 
380
* Remember execute bits, so that exports will work OK.
 
381
 
339
382
* Unify smart_add and plain Branch.add(); perhaps smart_add should
340
383
  just build a list of files to add and pass that to the regular add
341
384
  function.
342
385
 
343
386
* Function to list a directory, saying in which revision each file was
344
 
  last modified.  Useful for web and GUI interfaces, and slow to
 
387
  last modified.  Useful for web and gui interfaces, and slow to
345
388
  compute one file at a time.
346
389
  
347
390
  This will be done when we track file texts by referring to the
352
395
* Perhaps attempts to get locks should timeout after some period of
353
396
  time, or at least display a progress message.
354
397
 
 
398
* Split out upgrade functionality from check command into a separate
 
399
  ``bzr upgrade``.
 
400
 
355
401
* Don't pass around command classes but rather pass objects.  This'd
356
402
  make it cleaner to construct objects wrapping external commands.
357
403
 
358
404
* Track all merged-in revisions in a versioned add-only metafile.
359
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
 
360
413
* ``uncommit`` command that removes a revision from the end of the
361
414
  revision-history; just doing this is enough to remove the commit,
362
415
  and a new commit will automatically be made against the