~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to TODO

  • Committer: Aaron Bentley
  • Date: 2005-08-10 21:43:27 UTC
  • mto: (1092.1.41) (1185.3.4) (974.1.47)
  • mto: This revision was merged to the branch mainline in revision 1110.
  • Revision ID: abentley@panoramicfeedback.com-20050810214327-4e8c22e4cba24527
Eliminated ThreeWayInventory

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
* is_within_any is very very dodgy
 
21
 
 
22
* Merging add of a new file clashing with an existing file doesn't
 
23
  work; add gets an error that it's already versioned and the merge
 
24
  aborts.
 
25
 
 
26
* Merge should ignore the destination's working directory, otherwise
 
27
  we get an error about the statcache when pulling from a remote
 
28
  branch.
 
29
 
20
30
* Add of a file that was present in the base revision should put back
21
31
  the previous file-id.
22
32
 
 
33
* Not sure I'm happy with needing to pass a root id to EmptyTree;
 
34
  comparing anything against an EmptyTree with no root should have the
 
35
  same effect(?)
 
36
 
23
37
* Handle diff of files which do not have a trailing newline; probably
24
38
  requires patching difflib to get it exactly right, or otherwise
25
39
  calling out to GNU diff.
26
40
 
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
* Should be able to copy files between branches to preserve their
 
42
  file-id (and perhaps eventually parentage.)
38
43
 
39
44
* -r option should take a revision-id as well as a revno.
40
45
 
41
 
* ``bzr info`` could show space used by working tree, versioned files,
42
 
  unknown and ignored files. 
 
46
* allow ``bzr st -r 300`` to show a summary of changes since then.
43
47
 
44
48
* ``bzr info`` should count only people with distinct email addresses as
45
49
  different committers.  (Or perhaps only distinct userids?)
66
70
 
67
71
* ``bzr log DIR`` should give changes to any files within DIR.
68
72
 
69
 
* Check all commands have decent help.
70
 
 
71
73
* ``bzr inventory -r REV`` and perhaps unify this with ``bzr ls``,
72
74
  giving options to display ids, types, etc.
73
75
 
79
81
  temporary directory and then tar that up.)
80
82
 
81
83
  http://www.gelato.unsw.edu.au/archives/git/0504/2194.html
82
 
  
 
84
 
83
85
* RemoteBranch could maintain a cache either in memory or on disk.  We
84
86
  know more than an external cache might about which files are
85
87
  immutable and which can vary.  On the other hand, it's much simpler
103
105
 
104
106
* Statcache should possibly map all file paths to / separators
105
107
 
 
108
* quotefn doubles all backslashes on Windows; this is probably not the
 
109
  best thing to do.  What would be a better way to safely represent
 
110
  filenames?  Perhaps we could doublequote things containing spaces,
 
111
  on the principle that filenames containing quotes are unlikely?
 
112
  Nice for humans; less good for machine parsing.
 
113
 
 
114
* Patches should probably use only forward slashes, even on Windows,
 
115
  otherwise Unix patch can't apply them. (?)
 
116
 
 
117
* Branch.update_revisions() inefficiently fetches revisions from the
 
118
  remote server twice; once to find out what text and inventory they
 
119
  need and then again to actually get the thing.  This is a bit
 
120
  inefficient.
 
121
 
 
122
  One complicating factor here is that we don't really want to have
 
123
  revisions present in the revision-store until all their constituent
 
124
  parts are also stored.
 
125
 
 
126
  The basic problem is that RemoteBranch.get_revision() and similar
 
127
  methods return object, but what we really want is the raw XML, which
 
128
  can be popped into our own store.  That needs to be refactored.
 
129
 
 
130
* ``bzr status FOO`` where foo is ignored should say so.
 
131
 
 
132
* ``bzr mkdir A...`` should just create and add A.
 
133
 
 
134
* Guard against repeatedly merging any particular patch.
 
135
 
 
136
* More options for diff:
 
137
 
 
138
  - diff two revisions of the same tree
 
139
 
 
140
  - diff two different branches, optionally at different revisions
 
141
 
 
142
  - diff a particular file in another tree against the corresponding
 
143
    version in this tree (which should be the default if the second
 
144
    parameter is a tree root)
 
145
 
 
146
  - diff everything under a particular directory, in any of the above
 
147
    ways
 
148
 
 
149
  - diff two files inside the same tree, even if they have different
 
150
    ids
 
151
 
 
152
  - and, of course, tests for all this
 
153
 
 
154
* ``bzr add`` with no arguments should probably be the same as ``bzr add .``
 
155
 
 
156
* Reproducible performance benchmark to measure whether performance is 
 
157
  getting better or worse.
 
158
 
106
159
 
107
160
Medium things
108
161
-------------
145
198
  At the very least we could run diffstat over the diff, or perhaps
146
199
  read the status output from patch.  Just knowing which files might
147
200
  be modified would be enough to guide the add and commit.
148
 
  
 
201
 
149
202
  Given this we might be able to import patches at 1/second or better.
150
203
 
151
204
* Get branch over http.
187
240
 
188
241
* Handle symlinks in the working directory; at the very least it
189
242
  should be possible for them to be present and ignored/unknown
190
 
  without causing assertion failures. 
 
243
  without causing assertion failures.
191
244
 
192
245
  Eventually symlinks should be versioned.
193
246
 
195
248
  if the subdirectory is not already versioned.   Perhaps also require
196
249
  a ``--nested`` to protect against confusion.
197
250
 
198
 
* Branch names? 
 
251
* Branch names?
199
252
 
200
253
* More test framework:
201
254
 
203
256
    assert it's equal.
204
257
 
205
258
* There are too many methods on Branch() that really manipulate the
206
 
  WorkingTree.  They should be moved across.  
 
259
  WorkingTree.  They should be moved across.
207
260
 
208
261
  Also there are some methods which are duplicated on Tree and
209
262
  Inventory objects, and it should be made more clear which ones are
234
287
    object interface though, but perhaps that should just be a proxy
235
288
    for the elements.
236
289
 
237
 
  - Less special cases for the root directory. 
 
290
  - Less special cases for the root directory.
238
291
 
239
292
* Perhaps inventories should remember the revision in which each file
240
293
  was last changed, as well as its current state?  This is a bit
246
299
 
247
300
* It'd be nice to pipeline multiple HTTP requests.  Often we can
248
301
  predict what will be wanted in future: all revisions, or all texts
249
 
  in a particular revision, etc.  
 
302
  in a particular revision, etc.
250
303
 
251
304
  urlgrabber's docs say they are working on batched downloads; we
252
305
  could perhaps ride on that or just create a background thread (ew).
284
337
* Perhaps attempts to get locks should timeout after some period of
285
338
  time, or at least display a progress message.
286
339
 
 
340
* Split out upgrade functionality from check command into a separate
 
341
  ``bzr upgrade``.
 
342
 
 
343
* Don't pass around command classes but rather pass objects.  This'd
 
344
  make it cleaner to construct objects wrapping external commands.
 
345
 
 
346
* Track all merged-in revisions in a versioned add-only metafile.
 
347
 
287
348
 
288
349
Large things
289
350
------------
338
399
  a temporary directory.
339
400
 
340
401
  If the commit does not actually complete, we would rather the
341
 
  content was not left behind in the stores.  
 
402
  content was not left behind in the stores.
342
403
 
343
404
* Web interface
344
405