~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to TODO

  • Committer: Martin Pool
  • Date: 2005-08-12 15:28:37 UTC
  • Revision ID: mbp@sourcefrog.net-20050812152837-9f0bee4b51498c0e
- change default log format back to long
  (looks better with -v)

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