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

1

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

1

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

2

3

4

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

17

Small things

18

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

19

20

* is_within_any is very very dodgy

21

22

20

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

23

21

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

24

aborts.

22

aborts.

25

23

26

24

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

27

25

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

81

79

temporary directory and then tar that up.)

82

80

83

81

http://www.gelato.unsw.edu.au/archives/git/0504/2194.html

84

82

85

83

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

86

84

know more than an external cache might about which files are

87

85

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

112

110

Nice for humans; less good for machine parsing.

113

111

114

112

* Patches should probably use only forward slashes, even on Windows,

115

otherwise Unix patch can't apply them. (?)

113

otherwise Unix patch can't apply them. (?)

116

114

117

115

* Branch.update_revisions() inefficiently fetches revisions from the

118

116

remote server twice; once to find out what text and inventory they

119

117

need and then again to actually get the thing. This is a bit

120

inefficient.

118

inefficient.

121

119

122

120

One complicating factor here is that we don't really want to have

123

121

revisions present in the revision-store until all their constituent

132

130

* ``bzr mkdir A...`` should just create and add A.

133

131

134

132

* 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.

133

158

134

159

135

160

136

Medium things

198

174

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

199

175

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

200

176

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

201

177

202

178

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

203

179

204

180

* Get branch over http.

240

216

241

217

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

242

218

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

243

without causing assertion failures.

219

without causing assertion failures.

244

220

245

221

Eventually symlinks should be versioned.

246

222

248

224

if the subdirectory is not already versioned. Perhaps also require

249

225

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

250

226

251

* Branch names?

227

* Branch names?

252

228

253

229

* More test framework:

254

230

256

232

assert it's equal.

257

233

258

234

* There are too many methods on Branch() that really manipulate the

259

WorkingTree. They should be moved across.

235

WorkingTree. They should be moved across.

260

236

261

237

Also there are some methods which are duplicated on Tree and

262

238

Inventory objects, and it should be made more clear which ones are

287

263

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

288

264

for the elements.

289

265

290

- Less special cases for the root directory.

266

- Less special cases for the root directory.

291

267

292

268

* Perhaps inventories should remember the revision in which each file

293

269

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

299

275

300

276

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

301

277

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

302

in a particular revision, etc.

278

in a particular revision, etc.

303

279

304

280

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

305

281

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

399

375

a temporary directory.

400

376

401

377

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

402

content was not left behind in the stores.

378

content was not left behind in the stores.

403

379

404

380

* Web interface

405

381