~bzr-pqm/bzr/bzr.dev : revision 2397

1

.. -*- mode: indented-text; compile-command: "make -C doc" -*-

2

3

4

*******************

5

Things to do in bzr

6

*******************

7

8

9

See also various low-level TODOs in the source code. Try looking in

10

the list archive or on gmane.org for previous discussion of these

11

issues.

12

13

These are classified by approximate size: an hour or less, a day or

14

less, and several days or more.

15

16

17

Small things

18

------------

19

20

* Fix tests so that import errors caused by modules don't produce false reports

21

that the tests themselves don't exist.

22

23

* Fix tests so that one test failure doesn't prevent other tests from running

24

25

* print a message at the end of running the tests telling them that the

26

test log and output exists but can be removed

27

28

* tests for running the commit editor, and fix problem of not passing in

29

multiple arguments

30

31

* Merging add of a new file clashing with an existing file doesn't

32

work; add gets an error that it's already versioned and the merge

33

aborts.

34

35

* Merge should ignore the destination's working directory, otherwise

36

we get an error about the statcache when pulling from a remote

37

branch.

38

39

* Add of a file that was present in the base revision should put back

40

the previous file-id.

41

42

* Not sure I'm happy with needing to pass a root id to EmptyTree;

43

comparing anything against an EmptyTree with no root should have the

44

same effect(?)

45

46

* Handle diff of files which do not have a trailing newline; probably

47

requires patching difflib to get it exactly right, or otherwise

48

calling out to GNU diff.

49

50

* Should be able to copy files between branches to preserve their

51

file-id (and perhaps eventually parentage.)

52

53

* -r option should take a revision-id as well as a revno.

54

55

* ``bzr info`` should count only people with distinct email addresses as

56

different committers. (Or perhaps only distinct userids?)

57

58

* On Windows, command-line arguments should be `glob-expanded`__,

59

because the shell doesn't do this. However, there are probably some

60

commands where this shouldn't be done, such as 'bzr ignore', because

61

we want to accept globs.

62

63

* ``bzr ignore`` command that just adds a line to the ``.bzrignore`` file

64

and makes it versioned. Fix this to break symlinks.

65

66

* Any useful sanity checks in 'bzr ignore'? Perhaps give a warning if

67

they try to add a single file which is already versioned, or if they

68

add a pattern which already exists, or if it looks like they gave an

69

unquoted glob.

70

71

__ http://mail.python.org/pipermail/python-list/2001-April/037847.html

72

73

* Separate read and write version checks?

74

75

* ``bzr status DIR`` should give status on all files under that

76

directory.

77

78

* ``bzr log DIR`` should give changes to any files within DIR; at the

79

moment it only lists things which modify the specific named file

80

(and not its contents)

81

82

* ``bzr inventory -r REV`` and perhaps unify this with ``bzr ls``,

83

giving options to display ids, types, etc.

84

85

* RemoteBranch could maintain a cache either in memory or on disk. We

86

know more than an external cache might about which files are

87

immutable and which can vary. On the other hand, it's much simpler

88

to just use an external proxy cache.

89

90

Perhaps ~/.bzr/http-cache. Baz has a fairly simple cache under

91

~/.arch-cache, containing revision information encoded almost as a

92

bunch of archives. Perhaps we could simply store full paths.

93

94

* Maybe also store directories in the statcache so that we can quickly

95

identify that they still exist.

96

97

* Diff should show timestamps; for files from the working directory we

98

can use the file itself; for files from a revision we should use the

99

commit time of the revision.

100

101

* Perhaps split command infrastructure from the actual command

102

definitions.

103

104

* Cleaner support for negative boolean options like --no-recurse.

105

106

* Statcache should possibly map all file paths to / separators

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

* Guard against repeatedly merging any particular patch.

131

132

* More options for diff:

133

134

- diff two revisions of the same tree

135

136

- diff two different branches, optionally at different revisions

137

138

- diff a particular file in another tree against the corresponding

139

version in this tree (which should be the default if the second

140

parameter is a tree root)

141

142

- diff everything under a particular directory, in any of the above

143

ways

144

145

- diff two files inside the same tree, even if they have different

146

ids

147

148

- and, of course, tests for all this

149

150

* Reproducible performance benchmark to measure whether performance is

151

getting better or worse.

152

153

* ``bzr log -m foo`` should perhaps error if nothing matches?

154

155

* ``bzr diff -r 30 -r 40 foo.c`` or ``bzr diff -r30..40 foo.c``

156

157

If diffing between two branches then we probably want two -r

158

options, since the revisions don't form a range that can be

159

evaluated on either one.

160

161

* bzr diff shouldn't diff binary files

162

163

* setup.py install when run from a bzr tree should freeze the tree

164

revision-id into the installed bzr.

165

166

* bzr script should trap ImportError and perhaps give a better error

167

message?

168

169

* revert after a merge should possibly remove all the BASE/THIS/OTHER

170

files to get you back to where you were.

171

172

* files that are added and then deleted are still reported as added

173

174

* stores should raise KeyError, not IndexError

175

176

* merging from a remote branch seems to sometimes raise errors not

177

present locally

178

179

* should be possible to give a related branch when pulling from a

180

remote branch to make things faster

181

182

* sometimes gives "conflicting add" even when the contents are in fact

183

the same???

184

185

* BZRDIR should be in branch.py not __init__.py.

186

187

* bzrlib.delta.compare_trees() shouldn't need to sort all of the result

188

lists, since they are being added in alphabetical order. Write tests

189

to guarantee this, and remove the sort() calls.

190

191

Medium things

192

-------------

193

194

* merge should add all revision and inventory XML to the local store.

195

196

* check should give a warning for revisions that are named in the

197

chain but not actually present in the store.

198

199

* remove anything outside of the branch implementation that directly

200

accesses the stores.

201

202

* More efficient diff of only selected files. We should be able to

203

just get the id for the selected files, look up their location and

204

diff just those files. No need to traverse the entire inventories.

205

206

* Fix up Inventory objects to represent root object as an entry.

207

208

* Don't convert entire entry from ElementTree to an object when it is

209

read in, but rather wait until the program actually wants to know

210

about that node.

211

212

* Extract changes from one revision to the next to a text form

213

suitable for transmission over email.

214

215

* More test cases.

216

217

- ``missing`` command

218

219

- Selected-file commit

220

221

- Impossible selected-file commit: adding things in non-versioned

222

directories, crossing renames, etc.

223

224

* Write a reproducible benchmark, perhaps importing various kernel versions.

225

226

* Directly import diffs! It seems a bit redundant to need to rescan

227

the directory to work out what files diff added/deleted/changed when

228

all the information is there in the diff in the first place.

229

Getting the exact behaviour for added/deleted subdirectories etc

230

might be hard.

231

232

At the very least we could run diffstat over the diff, or perhaps

233

read the status output from patch. Just knowing which files might

234

be modified would be enough to guide the add and commit.

235

236

Given this we might be able to import patches at 1/second or better.

237

238

* revfile compression.

239

240

* Split inventory into per-directory files?

241

242

* Fix ignore file parsing:

243

244

- fnmatch is not the same as unix patterns

245

246

- perhaps add extended globs from rsh/rsync

247

248

- perhaps a pattern that matches only directories or non-directories

249

250

* Consider using Python logging library as well as/instead of

251

bzrlib.trace.

252

253

* Commands should give some progress indication by default.

254

255

- But quieten this with ``--silent``.

256

257

* Change to using gettext message localization.

258

259

* Make a clearer separation between internal and external bzrlib

260

interfaces. Make internal interfaces use protected names. Write at

261

least some documentation for those APIs, probably as docstrings.

262

263

Consider using ZopeInterface definitions for the external interface;

264

I think these are already used in PyBaz. They allow automatic

265

checking of the interface but may be unfamiliar to general Python

266

developers, so I'm not really keen.

267

268

* Commands to dump out all command help into a manpage or HTML file or

269

whatever.

270

271

* Handle symlinks in the working directory; at the very least it

272

should be possible for them to be present and ignored/unknown

273

without causing assertion failures.

274

275

Eventually symlinks should be versioned.

276

277

* Allow init in a subdirectory to create a nested repository, but only

278

if the subdirectory is not already versioned. Perhaps also require

279

a ``--nested`` to protect against confusion.

280

281

* Branch names?

282

283

* More test framework:

284

285

- Class that describes the state of a working tree so we can just

286

assert it's equal.

287

288

* Try using XSLT to add some formatting to REST-generated HTML. Or

289

maybe write a small Python program that specifies a header and foot

290

for the pages and calls into the docutils libraries.

291

292

* --format=xml for log, status and other commands.

293

294

* Attempting to explicitly add a file that's already added should give

295

a warning; however there should be no warning for directories (since

296

we scan for new children) or files encountered in a directory that's

297

being scanned.

298

299

* Better handling of possible collisions on case-losing filesystems;

300

make sure a single file does not get added twice under different

301

names.

302

303

* Clean up XML inventory:

304

305

- Use nesting rather than parent_id pointers.

306

307

- Hold the ElementTree in memory in the Inventory object and work

308

directly on that, rather than converting into Python objects every

309

time it is read in. Probably still expose it through some kind of

310

object interface though, but perhaps that should just be a proxy

311

for the elements.

312

313

- Less special cases for the root directory.

314

315

* Perhaps inventories should remember the revision in which each file

316

was last changed, as well as its current state? This is a bit

317

redundant but might often be interested to know.

318

319

* stat cache should perhaps only stat files as necessary, rather than

320

doing them all up-front. On the other hand, that disallows the

321

optimization of stating them in inode order.

322

323

* It'd be nice to pipeline multiple HTTP requests. Often we can

324

predict what will be wanted in future: all revisions, or all texts

325

in a particular revision, etc.

326

327

urlgrabber's docs say they are working on batched downloads; we

328

could perhaps ride on that or just create a background thread (ew).

329

330

* Paranoid mode where we never trust SHA-1 matches.

331

332

* --dry-run mode for commit? (Or maybe just run with

333

check-command=false?)

334

335

* Generally, be a bit more verbose unless --silent is specified.

336

337

* Function that finds all changes to files under a given directory;

338

perhaps log should use this if a directory is given.

339

340

* XML attributes might have trouble with filenames containing \n and

341

\r. Do we really want to support this? I think perhaps not.

342

343

* Unify smart_add and plain Branch.add(); perhaps smart_add should

344

just build a list of files to add and pass that to the regular add

345

function.

346

347

* Function to list a directory, saying in which revision each file was

348

last modified. Useful for web and GUI interfaces, and slow to

349

compute one file at a time.

350

351

This will be done when we track file texts by referring to the

352

version that created them.

353

354

* Check locking is correct during merge-related operations.

355

356

* Perhaps attempts to get locks should timeout after some period of

357

time, or at least display a progress message.

358

359

* Don't pass around command classes but rather pass objects. This'd

360

make it cleaner to construct objects wrapping external commands.

361

362

* Track all merged-in revisions in a versioned add-only metafile.

363

364

* ``uncommit`` command that removes a revision from the end of the

365

revision-history; just doing this is enough to remove the commit,

366

and a new commit will automatically be made against the

367

predecessor. This can be repeated.

368

369

It only makes sense to delete from the tail of history.

370

371

This has been implemented, but it does not remove the texts from

372

the store.

373

374

* ``bzrlib.lazy_import.lazy_import`` could check to see if a given

375

module has already been imported (look at ``sys.modules``). If it

376

has, then just import it directly, rather than creating a lazy

377

object.

378

379

380

Large things

381

------------

382

383

* Generate annotations from current file relative to previous

384

annotations.

385

386

- Is it necessary to store any kind of annotation where data was

387

deleted?

388

389

* Update revfile_ format and make it active:

390

391

- Texts should be identified by something keyed on the revision, not

392

an individual text-id. This is much more useful for annotate I

393

think; we want to map back to the revision that last changed it.

394

395

- Access revfile revisions through the Tree/Store classes.

396

397

- Check them from check commands.

398

399

- Store annotations.

400

401

.. _revfile: revfile.html

402

403

* Hooks for pre-commit, post-commit, etc.

404

405

Consider the security implications; probably should not enable hooks

406

for remotely-fetched branches by default.

407

408

* Pre-commit check. If this hook is defined, it needs to be handled

409

specially: create a temporary directory containing the tree as it

410

will be after the commit. This means excluding any ignored/unknown

411

files, and respecting selective commits. Run the pre-commit check

412

(e.g. compile and run test suite) in there.

413

414

Possibly this should be done by splitting the commit function into

415

several parts (under a single interface). It is already rather

416

large. Decomposition:

417

418

- find tree modifications and prepare in-memory inventory

419

420

- export that inventory to a temporary directory

421

422

- run the test in that temporary directory

423

424

- if that succeeded, continue to actually finish the commit

425

426

What should be done with the text of modified files while this is

427

underway? I don't think we want to count on holding them in memory

428

and we can't trust the working files to stay in one place so I

429

suppose we need to move them into the text store, or otherwise into

430

a temporary directory.

431

432

If the commit does not actually complete, we would rather the

433

content was not left behind in the stores.

434

435

* Web interface

436

437

* GUI (maybe in Python GTK+?)

438

439

* C library interface

440

441

* Expansion of $Id$ keywords within working files. Perhaps do this in

442

exports first as a simpler case because then we don't need to deal

443

with removing the tags on the way back in.

444

445

* ``bzr find``

446

447

Selftest

448

--------

449

450

* Write some benchmark tests

451

452

* we could display the ids of some tests selected by time to rune, or cputime,

453

rusage.

454

455

* We could run tests multiple times and report deviation/slowest/fastest.

456

457

* Gather lsprofile output for each test individually - log that somewhere.

458

459

* Should plugins be able to offer benchmark tests ?

460

461

CHANGESETS

462

----------

463

Ensure changeset command behaves properly w/revisions (e.g. 0)

464

Figure out whether testament-related bug is my problem

465

Get rid of the 'old' directory

466

Bundle signatures

467

What to do about ghost ancestors in remote branch that are present locally?

1

For things to do in Bazaar development, see

2

3

https://bugs.launchpad.net/bzr/

4

https://blueprints.launchpad.net/bzr/