← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to TODO

  • Committer: Martin Pool
  • Date: 2005-05-30 01:39:13 UTC
  • Revision ID: mbp@sourcefrog.net-20050530013913-4ac43c29e1302170
- make sure any bzr output is flushed before 
  running external diff

Show diffs side-by-side

added added

removed removed

Lines of Context:
TODO
26
26
 
27
27
* Import ElementTree update patch.
28
28
 
29
 
* Syntax should be ``bzr export -r REV``.
30
 
 
31
29
* Plugins that provide commands.  By just installing a file into some
32
30
  directory (e.g. ``/usr/share/bzr/plugins``) it should be possible to
33
31
  create new top-level commands (``bzr frob``).  Extensions can be
54
52
* ``bzr ignore`` command that just adds a line to the ``.bzrignore`` file
55
53
  and makes it versioned.  Fix this to break symlinks.
56
54
 
57
 
* ``bzr help commands`` should give a one-line summary of each command.
58
 
 
59
55
* Any useful sanity checks in 'bzr ignore'?  Perhaps give a warning if
60
56
  they try to add a single file which is already versioned, or if they
61
57
  add a pattern which already exists, or if it looks like they gave an
63
59
 
64
60
__ http://mail.python.org/pipermail/python-list/2001-April/037847.html
65
61
 
66
 
* Read and write locks on branch while it's open.
67
 
 
68
62
* Separate read and write version checks?
69
63
 
70
 
* ``bzr status FILE...``
 
64
* ``bzr status DIR`` should give status on all files under that
 
65
  directory.
 
66
 
 
67
* ``bzr log DIR`` should give changes to any files within DIR.
71
68
 
72
69
* Check all commands have decent help.
73
70
 
74
 
* Autogenerate argument/option help.
75
 
 
76
71
* ``bzr inventory -r REV`` and perhaps unify this with ``bzr ls``,
77
72
  giving options to display ids, types, etc.
78
73
 
79
 
* Atomic file class that renames into place when it's closed.
 
74
* Split BzrError into various more specific subclasses for different
 
75
  errors people might want to catch.
 
76
 
 
77
* If the export destination ends in '.tar', '.tar.gz', etc then create
 
78
  a tarball instead of a directory.  (Need to actually make a
 
79
  temporary directory and then tar that up.)
 
80
 
 
81
  http://www.gelato.unsw.edu.au/archives/git/0504/2194.html
 
82
  
 
83
* RemoteBranch could maintain a cache either in memory or on disk.  We
 
84
  know more than an external cache might about which files are
 
85
  immutable and which can vary.  On the other hand, it's much simpler
 
86
  to just use an external proxy cache.
 
87
 
 
88
* Maybe also store directories in the statcache so that we can quickly
 
89
  identify that they still exist.
 
90
 
 
91
* Diff should show timestamps; for files from the working directory we
 
92
  can use the file itself; for files from a revision we should use the
 
93
  commit time of the revision.
80
94
 
81
95
 
82
96
Medium things
83
97
-------------
84
98
 
85
 
* Display command grammar in help messages rather than hardcoding it.
86
 
 
87
 
* Change command functions into Command() objects, like in hct, and
88
 
  then the grammar can be described directly in there.  Since all
89
 
  option definitions are global we can define them just once and
90
 
  reference them from each command.
91
 
 
92
 
* Selective commit of only some files.
93
 
 
94
 
* Faster diff/status.  
95
 
 
96
 
  Status should be handled differently because it needs to report on
97
 
  deleted and unknown files.  diff only needs to deal with versioned
98
 
  files.
99
 
 
100
 
* Merge Aaron's merge code.
101
 
 
102
99
* Merge revert patch.
103
100
 
104
 
* Turn on stat cache code, and add optimization about avoiding
105
 
  dangerous cache entries.
106
 
 
107
101
* ``bzr mv`` that does either rename or move as in Unix.
108
102
 
109
 
* More efficient diff of only selected files.
 
103
* More efficient diff of only selected files.  We should be able to
 
104
  just get the id for the selected files, look up their location and
 
105
  diff just those files.  No need to traverse the entire inventories.
 
106
 
 
107
* ``bzr status DIR`` or ``bzr diff DIR`` should report on all changes
 
108
  under that directory.
110
109
 
111
110
* Fix up Inventory objects to represent root object as an entry.
112
111
 
113
 
* Don't convert entire entry from 
 
112
* Don't convert entire entry from ElementTree to an object when it is
 
113
  read in, but rather wait until the program actually wants to know
 
114
  about that node.
114
115
 
115
116
* Extract changes from one revision to the next to a text form
116
117
  suitable for transmission over email.
117
118
 
118
119
* More test cases.
119
120
 
 
121
  - Selected-file commit
 
122
 
 
123
  - Impossible selected-file commit: adding things in non-versioned
 
124
    directories, crossing renames, etc.
 
125
 
120
126
* Write a reproducible benchmark, perhaps importing various kernel versions.
121
127
 
122
 
* Change test.sh from Bourne shell into something in pure Python so
123
 
  that it can be more portable.
124
 
 
125
128
* Directly import diffs!  It seems a bit redundant to need to rescan
126
129
  the directory to work out what files diff added/deleted/changed when
127
130
  all the information is there in the diff in the first place.
153
156
* Consider using Python logging library as well as/instead of
154
157
  bzrlib.trace.
155
158
 
 
159
* Commands should give some progress indication by default.
 
160
 
 
161
  - But quieten this with ``--silent``.
 
162
 
156
163
* Change to using gettext message localization.
157
164
 
158
165
* Make a clearer separation between internal and external bzrlib
179
186
 
180
187
* Branch names? 
181
188
 
182
 
 
 
189
* More test framework:
 
190
 
 
191
  - Class that describes the state of a working tree so we can just
 
192
    assert it's equal.
 
193
 
 
194
* There are too many methods on Branch() that really manipulate the
 
195
  WorkingTree.  They should be moved across.  
 
196
 
 
197
  Also there are some methods which are duplicated on Tree and
 
198
  Inventory objects, and it should be made more clear which ones are
 
199
  proxies and which ones behave differently, and how.
 
200
 
 
201
* Try using XSLT to add some formatting to REST-generated HTML.  Or
 
202
  maybe write a small Python program that specifies a header and foot
 
203
  for the pages and calls into the docutils libraries.
 
204
 
 
205
* --format=xml for log, status and other commands.
 
206
 
 
207
* Attempting to explicitly add a file that's already added should give
 
208
  a warning; however there should be no warning for directories (since
 
209
  we scan for new children) or files encountered in a directory that's
 
210
  being scanned.
 
211
 
 
212
* Better handling of possible collisions on case-losing filesystems;
 
213
  make sure a single file does not get added twice under different
 
214
  names.
 
215
 
 
216
* Clean up XML inventory:
 
217
 
 
218
  - Use nesting rather than parent_id pointers.
 
219
 
 
220
  - Hold the ElementTree in memory in the Inventory object and work
 
221
    directly on that, rather than converting into Python objects every
 
222
    time it is read in.  Probably still exposoe it through some kind of
 
223
    object interface though, but perhaps that should just be a proxy
 
224
    for the elements.
 
225
 
 
226
  - Less special cases for the root directory. 
 
227
 
 
228
* Perhaps inventories should remember the revision in which each file
 
229
  was last changed, as well as its current state?  This is a bit
 
230
  redundant but might often be interested to know.
 
231
 
 
232
* stat cache should perhaps only stat files as necessary, rather than
 
233
  doing them all up-front.  On the other hand, that disallows the
 
234
  opimization of stating them in inode order.
 
235
 
 
236
* It'd be nice to pipeline multiple HTTP requests.  Often we can
 
237
  predict what will be wanted in future: all revisions, or all texts
 
238
  in a particular revision, etc.  
 
239
 
 
240
  urlgrabber's docs say they are working on batched downloads; we
 
241
  could perhaps ride on that or just create a background thread (ew).
 
242
 
 
243
* Paranoid mode where we never trust SHA-1 matches.
 
244
 
 
245
* Don't commit if there are no changes unless forced.
 
246
 
 
247
* --dry-run mode for commit?  (Or maybe just run with
 
248
  check-command=false?)
 
249
 
 
250
* Generally, be a bit more verbose unless --silent is specified.
 
251
 
 
252
* Function that finds all changes to files under a given directory;
 
253
  perhaps log should use this if a directory is given.
 
254
 
 
255
* XML attributes might have trouble with filenames containing \n and
 
256
  \r.  Do we really want to support this?  I think perhaps not.
 
257
 
 
258
* Remember execute bits, so that exports will work OK.
 
259
 
 
260
* Unify smart_add and plain Branch.add(); perhaps smart_add should
 
261
  just build a list of files to add and pass that to the regular add
 
262
  function.
183
263
 
184
264
 
185
265
Large things
216
296
  files, and respecting selective commits.  Run the pre-commit check
217
297
  (e.g. compile and run test suite) in there.
218
298
 
 
299
  Possibly this should be done by splitting the commit function into
 
300
  several parts (under a single interface).  It is already rather
 
301
  large.  Decomposition:
 
302
 
 
303
   - find tree modifications and prepare in-memory inventory
 
304
 
 
305
   - export that inventory to a temporary directory
 
306
 
 
307
   - run the test in that temporary directory
 
308
 
 
309
   - if that succeeded, continue to actually finish the commit
 
310
 
 
311
  What should be done with the text of modified files while this is
 
312
  underway?  I don't think we want to count on holding them in memory
 
313
  and we can't trust the working files to stay in one place so I
 
314
  suppose we need to move them into the text store, or otherwise into
 
315
  a temporary directory.
 
316
 
 
317
  If the commit does not actually complete, we would rather the
 
318
  content was not left behind in the stores.  
 
319
 
219
320
* Web interface
220
321
 
221
322
* GUI (maybe in Python GTK+?)