← 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-04-26 23:44:41 UTC
  • Revision ID: mbp@sourcefrog.net-20050426234441-0e9b3825bdaaa5c2
todo

Show diffs side-by-side

added added

removed removed

Lines of Context:
TODO
1
 
For things to do in Bazaar development, see
2
 
 
3
 
https://bugs.launchpad.net/bzr/
4
 
https://blueprints.launchpad.net/bzr/
 
1
                                                 -*- indented-text -*-
 
2
 
 
3
(See also various low-level TODOs in the source code.  Try looking in
 
4
the list archive or on gmane.org for previous discussion of these
 
5
issues, or )
 
6
 
 
7
Small things
 
8
------------
 
9
 
 
10
* Add of a file that was present in the base revision should put back
 
11
  the previous file-id.
 
12
 
 
13
* Handle diff of files which do not have a trailing newline; probably
 
14
  requires patching difflib to get it exactly right, or otherwise
 
15
  calling out to GNU diff.
 
16
 
 
17
* Import ElementTree update patch.
 
18
 
 
19
* Syntax should be "bzr export -r REV".
 
20
 
 
21
* "cat -rREV FILE"
 
22
 
 
23
* Plugins that provide commands.  By just installing a file into some
 
24
  directory (e.g. /usr/share/bzr/plugins) it should be possible to
 
25
  create new top-level commands ("bzr frob").  Extensions can be
 
26
  written in either Python (in which case they use the bzrlib API) or
 
27
  in a separate process (in sh, C, whatever).   It should be possible
 
28
  to get help for plugin commands.
 
29
 
 
30
* Smart rewrap text in help messages to fit in $COLUMNS (or equivalent
 
31
  on Windows)
 
32
 
 
33
* -r option should take a revision-id as well as a revno.
 
34
 
 
35
* "bzr info" could show space used by working tree, versioned files,
 
36
  unknown and ignored files. 
 
37
 
 
38
* "bzr info" should count only people with distinct email addresses as
 
39
  different committers.  (Or perhaps only distinct userids?)
 
40
 
 
41
 
 
42
Medium things
 
43
-------------
 
44
 
 
45
* Faster diff/status.  
 
46
 
 
47
  Status should be handled differently because it needs to report on
 
48
  deleted and unknown files.  diff only needs to deal with versioned
 
49
  files.
 
50
 
 
51
* Merge Aaron's merge code.
 
52
 
 
53
* Merge revert patch.
 
54
 
 
55
* Turn on stat cache code, and add optimization about avoiding
 
56
  dangerous cache entries.
 
57
 
 
58
* mv command?
 
59
 
 
60
* More efficient diff of only selected files.
 
61
 
 
62
* Fix up Inventory objects to represent root object as an entry.
 
63
 
 
64
* Don't convert entire entry from 
 
65
 
 
66
* Extract changes from one revision to the next to a text form
 
67
  suitable for transmission over email.
 
68
 
 
69
* More test cases.
 
70
 
 
71
* Write a reproducible benchmark, perhaps importing various kernel versions.
 
72
 
 
73
* Change test.sh from Bourne shell into something in pure Python so
 
74
  that it can be more portable.
 
75
 
 
76
* Directly import diffs!  It seems a bit redundant to need to rescan
 
77
  the directory to work out what files diff added/deleted/changed when
 
78
  all the information is there in the diff in the first place.
 
79
  Getting the exact behaviour for added/deleted subdirectories etc
 
80
  might be hard.
 
81
 
 
82
  At the very least we could run diffstat over the diff, or perhaps
 
83
  read the status output from patch.  Just knowing which files might
 
84
  be modified would be enough to guide the add and commit.
 
85
  
 
86
  Given this we might be able to import patches at 1/second or better.
 
87
 
 
88
* Get branch over http.
 
89
 
 
90
* Pull pure updates over http.
 
91
 
 
92
* revfile compression.
 
93
 
 
94
* Split inventory into per-directory files.
 
95
 
 
96
* Fix ignore file parsing:
 
97
 
 
98
  - fnmatch is not the same as unix patterns
 
99
 
 
100
  - perhaps add extended globs from rsh/rsync
 
101
 
 
102
  - perhaps a pattern that matches only directories or non-directories
 
103
 
 
104
* Expansion of $Id$ tags within working files.  Perhaps do this in
 
105
  exports first as a simpler case because then we don't need to deal
 
106
  with removing the tags on the way back in.
 
107
 
 
108
 
 
109
Large things
 
110
------------
 
111
 
 
112
* Web interface
 
113
 
 
114
* GUI (maybe in Python GTK+?)
 
115
 
 
116
* C library interface