← 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-12 02:18:48 UTC
  • Revision ID: mbp@sourcefrog.net-20050512021848-d1a727373aee2c85
- WorkingTree loads statcache in constructor and holds
  it permanently

Show diffs side-by-side

added added

removed removed

Lines of Context:
TODO
84
84
 
85
85
  http://www.gelato.unsw.edu.au/archives/git/0504/2194.html
86
86
  
 
87
* testbzr should by default test the bzr binary in the same directory
 
88
  as the testbzr script, or take a path to it as a first parameter.
 
89
 
 
90
  Should show the version from bzr and the path name.
 
91
 
87
92
* RemoteBranch could maintain a cache either in memory or on disk.  We
88
93
  know more than an external cache might about which files are
89
94
  immutable and which can vary.  On the other hand, it's much simpler
101
106
  option definitions are global we can define them just once and
102
107
  reference them from each command.
103
108
 
 
109
* Selective commit of only some files.
 
110
 
104
111
* Merge Aaron's merge code.
105
112
 
106
113
* Merge revert patch.
123
130
 
124
131
* More test cases.
125
132
 
126
 
  - Selected-file commit
127
 
 
128
 
  - Impossible selected-file commit: adding things in non-versioned
129
 
    directories, crossing renames, etc.
130
 
 
131
133
* Write a reproducible benchmark, perhaps importing various kernel versions.
132
134
 
133
135
* Change test.sh from Bourne shell into something in pure Python so
252
254
 
253
255
* Paranoid mode where we never trust SHA-1 matches.
254
256
 
255
 
* Don't commit if there are no changes unless forced.
256
 
 
257
 
* --dry-run mode for commit?  
258
 
 
259
 
* Generally, be a bit more verbose unless --silent is specified.
260
 
 
261
257
 
262
258
Large things
263
259
------------
293
289
  files, and respecting selective commits.  Run the pre-commit check
294
290
  (e.g. compile and run test suite) in there.
295
291
 
296
 
  Possibly this should be done by splitting the commit function into
297
 
  several parts (under a single interface).  It is already rather
298
 
  large.  Decomposition:
299
 
 
300
 
   - find tree modifications and prepare in-memory inventory
301
 
 
302
 
   - export that inventory to a temporary directory
303
 
 
304
 
   - run the test in that temporary directory
305
 
 
306
 
   - if that succeeded, continue to actually finish the commit
307
 
 
308
 
  What should be done with the text of modified files while this is
309
 
  underway?  I don't think we want to count on holding them in memory
310
 
  and we can't trust the working files to stay in one place so I
311
 
  suppose we need to move them into the text store, or otherwise into
312
 
  a temporary directory.
313
 
 
314
 
  If the commit does not actually complete, we would rather the
315
 
  content was not left behind in the stores.  
316
 
 
317
292
* Web interface
318
293
 
319
294
* GUI (maybe in Python GTK+?)