~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to TODO

  • Committer: Martin Pool
  • Date: 2005-05-16 01:57:48 UTC
  • Revision ID: mbp@sourcefrog.net-20050516015748-e217422f1da5794a
- disallow slash in store ids

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
 
* Merging add of a new file clashing with an existing file doesn't
21
 
  work; add gets an error that it's already versioned and the merge
22
 
  aborts.
23
 
 
24
 
* Merge should ignore the destination's working directory, otherwise
25
 
  we get an error about the statcache when pulling from a remote
26
 
  branch.
27
 
 
28
20
* Add of a file that was present in the base revision should put back
29
21
  the previous file-id.
30
22
 
31
 
* Not sure I'm happy with needing to pass a root id to EmptyTree;
32
 
  comparing anything against an EmptyTree with no root should have the
33
 
  same effect(?)
34
 
 
35
23
* Handle diff of files which do not have a trailing newline; probably
36
24
  requires patching difflib to get it exactly right, or otherwise
37
25
  calling out to GNU diff.
38
26
 
39
 
* Should be able to copy files between branches to preserve their
40
 
  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)
41
38
 
42
39
* -r option should take a revision-id as well as a revno.
43
40
 
44
 
* 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. 
45
43
 
46
44
* ``bzr info`` should count only people with distinct email addresses as
47
45
  different committers.  (Or perhaps only distinct userids?)
68
66
 
69
67
* ``bzr log DIR`` should give changes to any files within DIR.
70
68
 
 
69
* Check all commands have decent help.
 
70
 
71
71
* ``bzr inventory -r REV`` and perhaps unify this with ``bzr ls``,
72
72
  giving options to display ids, types, etc.
73
73
 
 
74
* Atomic file class that renames into place when it's closed.
 
75
 
 
76
* Don't abort if ``~/.bzr.log`` can't be used.
 
77
 
74
78
* Split BzrError into various more specific subclasses for different
75
79
  errors people might want to catch.
76
80
 
79
83
  temporary directory and then tar that up.)
80
84
 
81
85
  http://www.gelato.unsw.edu.au/archives/git/0504/2194.html
82
 
 
 
86
  
83
87
* RemoteBranch could maintain a cache either in memory or on disk.  We
84
88
  know more than an external cache might about which files are
85
89
  immutable and which can vary.  On the other hand, it's much simpler
86
90
  to just use an external proxy cache.
87
91
 
88
 
  Perhaps ~/.bzr/http-cache.  Baz has a fairly simple cache under
89
 
  ~/.arch-cache, containing revision information encoded almost as a
90
 
  bunch of archives.  Perhaps we could simply store full paths.
91
 
 
92
92
* Maybe also store directories in the statcache so that we can quickly
93
93
  identify that they still exist.
94
94
 
95
 
* Diff should show timestamps; for files from the working directory we
96
 
  can use the file itself; for files from a revision we should use the
97
 
  commit time of the revision.
98
 
 
99
 
* Perhaps split command infrastructure from the actual command
100
 
  definitions.
101
 
 
102
 
* Cleaner support for negative boolean options like --no-recurse.
103
 
 
104
 
* Statcache should possibly map all file paths to / separators
105
 
 
106
 
* quotefn doubles all backslashes on Windows; this is probably not the
107
 
  best thing to do.  What would be a better way to safely represent
108
 
  filenames?  Perhaps we could doublequote things containing spaces,
109
 
  on the principle that filenames containing quotes are unlikely?
110
 
  Nice for humans; less good for machine parsing.
111
 
 
112
 
* Patches should probably use only forward slashes, even on Windows,
113
 
  otherwise Unix patch can't apply them. (?)
114
 
 
115
 
* Branch.update_revisions() inefficiently fetches revisions from the
116
 
  remote server twice; once to find out what text and inventory they
117
 
  need and then again to actually get the thing.  This is a bit
118
 
  inefficient.
119
 
 
120
 
  One complicating factor here is that we don't really want to have
121
 
  revisions present in the revision-store until all their constituent
122
 
  parts are also stored.
123
 
 
124
 
  The basic problem is that RemoteBranch.get_revision() and similar
125
 
  methods return object, but what we really want is the raw XML, which
126
 
  can be popped into our own store.  That needs to be refactored.
127
 
 
128
 
* ``bzr status FOO`` where foo is ignored should say so.
129
 
 
130
 
* ``bzr mkdir A...`` should just create and add A.
131
 
 
132
 
* Guard against repeatedly merging any particular patch.
133
 
 
134
 
* More options for diff:
135
 
 
136
 
  - diff two revisions of the same tree
137
 
 
138
 
  - diff two different branches, optionally at different revisions
139
 
 
140
 
  - diff a particular file in another tree against the corresponding
141
 
    version in this tree (which should be the default if the second
142
 
    parameter is a tree root)
143
 
 
144
 
  - diff everything under a particular directory, in any of the above
145
 
    ways
146
 
 
147
 
  - diff two files inside the same tree, even if they have different
148
 
    ids
149
 
 
150
 
  - and, of course, tests for all this
151
 
 
152
 
* stat-cache update is too slow for some reason - why is Python making
153
 
  a lot of futex calls?
154
 
  
155
 
* ``bzr add`` with no arguments should probably be the same as ``bzr add .``
156
 
 
157
 
 
158
95
 
159
96
Medium things
160
97
-------------
161
98
 
 
99
* Change command functions into Command() objects, like in hct, and
 
100
  then the grammar can be described directly in there.  Since all
 
101
  option definitions are global we can define them just once and
 
102
  reference them from each command.
 
103
 
 
104
* Merge Aaron's merge code.
 
105
 
162
106
* Merge revert patch.
163
107
 
164
108
* ``bzr mv`` that does either rename or move as in Unix.
172
116
 
173
117
* Fix up Inventory objects to represent root object as an entry.
174
118
 
175
 
* Don't convert entire entry from ElementTree to an object when it is
176
 
  read in, but rather wait until the program actually wants to know
177
 
  about that node.
 
119
* Don't convert entire entry from 
178
120
 
179
121
* Extract changes from one revision to the next to a text form
180
122
  suitable for transmission over email.
188
130
 
189
131
* Write a reproducible benchmark, perhaps importing various kernel versions.
190
132
 
 
133
* Change test.sh from Bourne shell into something in pure Python so
 
134
  that it can be more portable.
 
135
 
191
136
* Directly import diffs!  It seems a bit redundant to need to rescan
192
137
  the directory to work out what files diff added/deleted/changed when
193
138
  all the information is there in the diff in the first place.
197
142
  At the very least we could run diffstat over the diff, or perhaps
198
143
  read the status output from patch.  Just knowing which files might
199
144
  be modified would be enough to guide the add and commit.
200
 
 
 
145
  
201
146
  Given this we might be able to import patches at 1/second or better.
202
147
 
203
148
* Get branch over http.
239
184
 
240
185
* Handle symlinks in the working directory; at the very least it
241
186
  should be possible for them to be present and ignored/unknown
242
 
  without causing assertion failures.
 
187
  without causing assertion failures. 
243
188
 
244
189
  Eventually symlinks should be versioned.
245
190
 
247
192
  if the subdirectory is not already versioned.   Perhaps also require
248
193
  a ``--nested`` to protect against confusion.
249
194
 
250
 
* Branch names?
 
195
* Branch names? 
251
196
 
252
197
* More test framework:
253
198
 
255
200
    assert it's equal.
256
201
 
257
202
* There are too many methods on Branch() that really manipulate the
258
 
  WorkingTree.  They should be moved across.
 
203
  WorkingTree.  They should be moved across.  
259
204
 
260
205
  Also there are some methods which are duplicated on Tree and
261
206
  Inventory objects, and it should be made more clear which ones are
286
231
    object interface though, but perhaps that should just be a proxy
287
232
    for the elements.
288
233
 
289
 
  - Less special cases for the root directory.
 
234
  - Less special cases for the root directory. 
290
235
 
291
236
* Perhaps inventories should remember the revision in which each file
292
237
  was last changed, as well as its current state?  This is a bit
298
243
 
299
244
* It'd be nice to pipeline multiple HTTP requests.  Often we can
300
245
  predict what will be wanted in future: all revisions, or all texts
301
 
  in a particular revision, etc.
 
246
  in a particular revision, etc.  
302
247
 
303
248
  urlgrabber's docs say they are working on batched downloads; we
304
249
  could perhaps ride on that or just create a background thread (ew).
305
250
 
 
251
* Should be a signature at the top of the cache file.
 
252
 
306
253
* Paranoid mode where we never trust SHA-1 matches.
307
254
 
308
 
* Don't commit if there are no changes unless forced.
309
 
 
310
 
* --dry-run mode for commit?  (Or maybe just run with
311
 
  check-command=false?)
312
 
 
313
 
* Generally, be a bit more verbose unless --silent is specified.
314
 
 
315
 
* Function that finds all changes to files under a given directory;
316
 
  perhaps log should use this if a directory is given.
317
 
 
318
 
* XML attributes might have trouble with filenames containing \n and
319
 
  \r.  Do we really want to support this?  I think perhaps not.
320
 
 
321
 
* Remember execute bits, so that exports will work OK.
322
 
 
323
 
* Unify smart_add and plain Branch.add(); perhaps smart_add should
324
 
  just build a list of files to add and pass that to the regular add
325
 
  function.
326
 
 
327
 
* Function to list a directory, saying in which revision each file was
328
 
  last modified.  Useful for web and gui interfaces, and slow to
329
 
  compute one file at a time.
330
 
 
331
 
* unittest is standard, but the results are kind of ugly; would be
332
 
  nice to make it cleaner.
333
 
 
334
 
* Check locking is correct during merge-related operations.
335
 
 
336
 
* Perhaps attempts to get locks should timeout after some period of
337
 
  time, or at least display a progress message.
338
 
 
339
 
* Split out upgrade functionality from check command into a separate
340
 
  ``bzr upgrade``.
341
 
 
342
 
* Don't pass around command classes but rather pass objects.  This'd
343
 
  make it cleaner to construct objects wrapping external commands.
344
 
 
345
 
* Track all merged-in revisions in a versioned add-only metafile.
346
 
 
347
255
 
348
256
Large things
349
257
------------
379
287
  files, and respecting selective commits.  Run the pre-commit check
380
288
  (e.g. compile and run test suite) in there.
381
289
 
382
 
  Possibly this should be done by splitting the commit function into
383
 
  several parts (under a single interface).  It is already rather
384
 
  large.  Decomposition:
385
 
 
386
 
   - find tree modifications and prepare in-memory inventory
387
 
 
388
 
   - export that inventory to a temporary directory
389
 
 
390
 
   - run the test in that temporary directory
391
 
 
392
 
   - if that succeeded, continue to actually finish the commit
393
 
 
394
 
  What should be done with the text of modified files while this is
395
 
  underway?  I don't think we want to count on holding them in memory
396
 
  and we can't trust the working files to stay in one place so I
397
 
  suppose we need to move them into the text store, or otherwise into
398
 
  a temporary directory.
399
 
 
400
 
  If the commit does not actually complete, we would rather the
401
 
  content was not left behind in the stores.
402
 
 
403
290
* Web interface
404
291
 
405
292
* GUI (maybe in Python GTK+?)