~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to TODO

  • Committer: Martin Pool
  • Date: 2005-06-06 04:47:33 UTC
  • Revision ID: mbp@sourcefrog.net-20050606044733-e902b05ac1747cd2
- fix invocation of testbzr when giving explicit bzr location

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
 
 
41
20
* Add of a file that was present in the base revision should put back
42
21
  the previous file-id.
43
22
 
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
 
 
48
23
* Handle diff of files which do not have a trailing newline; probably
49
24
  requires patching difflib to get it exactly right, or otherwise
50
25
  calling out to GNU diff.
51
26
 
52
 
* Should be able to copy files between branches to preserve their
53
 
  file-id (and perhaps eventually parentage.)
 
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)
54
38
 
55
39
* -r option should take a revision-id as well as a revno.
56
40
 
57
 
* allow ``bzr st -r 300`` to show a summary of changes since then.
 
41
* ``bzr info`` could show space used by working tree, versioned files,
 
42
  unknown and ignored files. 
58
43
 
59
44
* ``bzr info`` should count only people with distinct email addresses as
60
45
  different committers.  (Or perhaps only distinct userids?)
79
64
* ``bzr status DIR`` should give status on all files under that
80
65
  directory.
81
66
 
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)
 
67
* ``bzr log DIR`` should give changes to any files within DIR.
 
68
 
 
69
* Check all commands have decent help.
85
70
 
86
71
* ``bzr inventory -r REV`` and perhaps unify this with ``bzr ls``,
87
72
  giving options to display ids, types, etc.
94
79
  temporary directory and then tar that up.)
95
80
 
96
81
  http://www.gelato.unsw.edu.au/archives/git/0504/2194.html
97
 
 
 
82
  
98
83
* RemoteBranch could maintain a cache either in memory or on disk.  We
99
84
  know more than an external cache might about which files are
100
85
  immutable and which can vary.  On the other hand, it's much simpler
118
103
 
119
104
* Statcache should possibly map all file paths to / separators
120
105
 
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
106
 
205
107
Medium things
206
108
-------------
207
109
 
208
 
* merge should add all revision and inventory XML to the local store.
209
 
 
210
 
* check should give a warning for revisions that are named in the
211
 
  chain but not actually present in the store.
212
 
 
213
 
* remove anything outside of the branch implementation that directly
214
 
  accesses the stores.
 
110
* Merge revert patch.
 
111
 
 
112
* ``bzr mv`` that does either rename or move as in Unix.
215
113
 
216
114
* More efficient diff of only selected files.  We should be able to
217
115
  just get the id for the selected files, look up their location and
231
129
 
232
130
* More test cases.
233
131
 
234
 
  - ``missing`` command
235
 
 
236
132
  - Selected-file commit
237
133
 
238
134
  - Impossible selected-file commit: adding things in non-versioned
249
145
  At the very least we could run diffstat over the diff, or perhaps
250
146
  read the status output from patch.  Just knowing which files might
251
147
  be modified would be enough to guide the add and commit.
252
 
 
 
148
  
253
149
  Given this we might be able to import patches at 1/second or better.
254
150
 
 
151
* Get branch over http.
 
152
 
 
153
* Pull pure updates over http.
 
154
 
255
155
* revfile compression.
256
156
 
257
 
* Split inventory into per-directory files?
 
157
* Split inventory into per-directory files.
258
158
 
259
159
* Fix ignore file parsing:
260
160
 
287
187
 
288
188
* Handle symlinks in the working directory; at the very least it
289
189
  should be possible for them to be present and ignored/unknown
290
 
  without causing assertion failures.
 
190
  without causing assertion failures. 
291
191
 
292
192
  Eventually symlinks should be versioned.
293
193
 
295
195
  if the subdirectory is not already versioned.   Perhaps also require
296
196
  a ``--nested`` to protect against confusion.
297
197
 
298
 
* Branch names?
 
198
* Branch names? 
299
199
 
300
200
* More test framework:
301
201
 
303
203
    assert it's equal.
304
204
 
305
205
* There are too many methods on Branch() that really manipulate the
306
 
  WorkingTree.  They should be moved across.
 
206
  WorkingTree.  They should be moved across.  
307
207
 
308
208
  Also there are some methods which are duplicated on Tree and
309
209
  Inventory objects, and it should be made more clear which ones are
334
234
    object interface though, but perhaps that should just be a proxy
335
235
    for the elements.
336
236
 
337
 
  - Less special cases for the root directory.
 
237
  - Less special cases for the root directory. 
338
238
 
339
239
* Perhaps inventories should remember the revision in which each file
340
240
  was last changed, as well as its current state?  This is a bit
346
246
 
347
247
* It'd be nice to pipeline multiple HTTP requests.  Often we can
348
248
  predict what will be wanted in future: all revisions, or all texts
349
 
  in a particular revision, etc.
 
249
  in a particular revision, etc.  
350
250
 
351
251
  urlgrabber's docs say they are working on batched downloads; we
352
252
  could perhaps ride on that or just create a background thread (ew).
375
275
* Function to list a directory, saying in which revision each file was
376
276
  last modified.  Useful for web and gui interfaces, and slow to
377
277
  compute one file at a time.
378
 
  
379
 
  This will be done when we track file texts by referring to the
380
 
  version that created them. 
381
 
 
382
 
* Check locking is correct during merge-related operations.
383
 
 
384
 
* Perhaps attempts to get locks should timeout after some period of
385
 
  time, or at least display a progress message.
386
 
 
387
 
* Split out upgrade functionality from check command into a separate
388
 
  ``bzr upgrade``.
389
 
 
390
 
* Don't pass around command classes but rather pass objects.  This'd
391
 
  make it cleaner to construct objects wrapping external commands.
392
 
 
393
 
* Track all merged-in revisions in a versioned add-only metafile.
394
 
 
395
 
* ``pull --clobber`` should discard any local changes not present
396
 
  remotely.  Not generally what you want, but possibly useful when
397
 
  you're just mirroring another branch and want to keep tracking it
398
 
  even when they e.g. uncommit or make similar non-forward movements.
399
 
  Also for push I suppose.  Clobber may not be the best name, maybe
400
 
  ``--destroy``?
401
 
 
402
 
* ``uncommit`` command that removes a revision from the end of the
403
 
  revision-history; just doing this is enough to remove the commit,
404
 
  and a new commit will automatically be made against the
405
 
  predecessor.  This can be repeated.
406
 
 
407
 
  It only makes sense to delete from the tail of history, not from the
408
 
  end.
409
 
 
410
 
  The revision, its inventory and texts remain floating in the store.
411
 
  We should perhaps add the revision to a list of removed-commits, so
412
 
  that it can be restored or at least accounted for when checking
413
 
  consistency.  This file would not be versioned, and probably should
414
 
  not propagate when branched.
415
 
 
416
 
  If we track merged revisions then we need to update this list too.
417
 
  If the list is stored in a weave it's easy (implicit): the version
418
 
  of the list can remain but it won't be referenced anymore.  It's
419
 
  probably best to just store this list in a weave in the first place
420
 
  and be done.
 
278
 
 
279
* unittest is standard, but the results are kind of ugly; would be
 
280
  nice to make it cleaner.
421
281
 
422
282
 
423
283
Large things
473
333
  a temporary directory.
474
334
 
475
335
  If the commit does not actually complete, we would rather the
476
 
  content was not left behind in the stores.
 
336
  content was not left behind in the stores.  
477
337
 
478
338
* Web interface
479
339