← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to TODO

  • Committer: Aaron Bentley
  • Date: 2005-07-29 17:19:16 UTC
  • mto: (1092.1.41) (1185.3.4) (974.1.47)
  • mto: This revision was merged to the branch mainline in revision 1020.
  • Revision ID: abentley@panoramicfeedback.com-20050729171916-322fd81b451d2e3e
Added merge-type parameter to merge.

Show diffs side-by-side

added added

removed removed

Lines of Context:
TODO
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
 
 
41
* Should be able to copy files between branches to preserve their
 
42
  file-id (and perhaps eventually parentage.)
 
43
 
27
44
* -r option should take a revision-id as well as a revno.
28
45
 
 
46
* allow ``bzr st -r 300`` to show a summary of changes since then.
 
47
 
29
48
* ``bzr info`` should count only people with distinct email addresses as
30
49
  different committers.  (Or perhaps only distinct userids?)
31
50
 
62
81
  temporary directory and then tar that up.)
63
82
 
64
83
  http://www.gelato.unsw.edu.au/archives/git/0504/2194.html
65
 
  
 
84
 
66
85
* RemoteBranch could maintain a cache either in memory or on disk.  We
67
86
  know more than an external cache might about which files are
68
87
  immutable and which can vary.  On the other hand, it's much simpler
93
112
  Nice for humans; less good for machine parsing.
94
113
 
95
114
* Patches should probably use only forward slashes, even on Windows,
96
 
  otherwise Unix patch can't apply them. (?) 
 
115
  otherwise Unix patch can't apply them. (?)
97
116
 
98
117
* Branch.update_revisions() inefficiently fetches revisions from the
99
118
  remote server twice; once to find out what text and inventory they
100
119
  need and then again to actually get the thing.  This is a bit
101
 
  inefficient. 
 
120
  inefficient.
102
121
 
103
122
  One complicating factor here is that we don't really want to have
104
123
  revisions present in the revision-store until all their constituent
113
132
* ``bzr mkdir A...`` should just create and add A.
114
133
 
115
134
* Guard against repeatedly merging any particular patch.
116
 
  
 
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.
117
158
 
118
159
 
119
160
Medium things
157
198
  At the very least we could run diffstat over the diff, or perhaps
158
199
  read the status output from patch.  Just knowing which files might
159
200
  be modified would be enough to guide the add and commit.
160
 
  
 
201
 
161
202
  Given this we might be able to import patches at 1/second or better.
162
203
 
163
204
* Get branch over http.
199
240
 
200
241
* Handle symlinks in the working directory; at the very least it
201
242
  should be possible for them to be present and ignored/unknown
202
 
  without causing assertion failures. 
 
243
  without causing assertion failures.
203
244
 
204
245
  Eventually symlinks should be versioned.
205
246
 
207
248
  if the subdirectory is not already versioned.   Perhaps also require
208
249
  a ``--nested`` to protect against confusion.
209
250
 
210
 
* Branch names? 
 
251
* Branch names?
211
252
 
212
253
* More test framework:
213
254
 
215
256
    assert it's equal.
216
257
 
217
258
* There are too many methods on Branch() that really manipulate the
218
 
  WorkingTree.  They should be moved across.  
 
259
  WorkingTree.  They should be moved across.
219
260
 
220
261
  Also there are some methods which are duplicated on Tree and
221
262
  Inventory objects, and it should be made more clear which ones are
246
287
    object interface though, but perhaps that should just be a proxy
247
288
    for the elements.
248
289
 
249
 
  - Less special cases for the root directory. 
 
290
  - Less special cases for the root directory.
250
291
 
251
292
* Perhaps inventories should remember the revision in which each file
252
293
  was last changed, as well as its current state?  This is a bit
258
299
 
259
300
* It'd be nice to pipeline multiple HTTP requests.  Often we can
260
301
  predict what will be wanted in future: all revisions, or all texts
261
 
  in a particular revision, etc.  
 
302
  in a particular revision, etc.
262
303
 
263
304
  urlgrabber's docs say they are working on batched downloads; we
264
305
  could perhaps ride on that or just create a background thread (ew).
358
399
  a temporary directory.
359
400
 
360
401
  If the commit does not actually complete, we would rather the
361
 
  content was not left behind in the stores.  
 
402
  content was not left behind in the stores.
362
403
 
363
404
* Web interface
364
405