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

1

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

1

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

2

3

4

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

19

20

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

21

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

22

aborts.

22

aborts.

23

24

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

25

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

79

temporary directory and then tar that up.)

80

81

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

82

83

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

84

know more than an external cache might about which files are

85

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

110

Nice for humans; less good for machine parsing.

111

112

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

113

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

113

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

114

115

* Branch.update_revisions() inefficiently fetches revisions from the

116

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

117

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

118

inefficient.

118

inefficient.

119

120

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

121

revisions present in the revision-store until all their constituent

130

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

131

132

* Guard against repeatedly merging any particular patch.

133

134

* More options for diff:

135

136

- diff two revisions of the same tree

137

138

- diff two different branches, optionally at different revisions

139

140

- diff a particular file in another tree against the corresponding

141

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

142

parameter is a tree root)

143

144

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

145

ways

146

147

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

148

ids

149

150

- and, of course, tests for all this

151

152

* stat-cache update is too slow for some reason - why is Python making

153

a lot of futex calls?

154

134

155

135

156

136

157

Medium things

174

195

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

175

196

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

176

197

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

177

198

178

199

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

179

200

180

201

* Get branch over http.

216

237

217

238

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

218

239

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

219

without causing assertion failures.

240

without causing assertion failures.

220

241

221

242

Eventually symlinks should be versioned.

222

243

224

245

if the subdirectory is not already versioned. Perhaps also require

225

246

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

226

247

227

* Branch names?

248

* Branch names?

228

249

229

250

* More test framework:

230

251

232

253

assert it's equal.

233

254

234

255

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

235

WorkingTree. They should be moved across.

256

WorkingTree. They should be moved across.

236

257

237

258

Also there are some methods which are duplicated on Tree and

238

259

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

263

284

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

264

285

for the elements.

265

286

266

- Less special cases for the root directory.

287

- Less special cases for the root directory.

267

288

268

289

* Perhaps inventories should remember the revision in which each file

269

290

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

275

296

276

297

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

277

298

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

278

in a particular revision, etc.

299

in a particular revision, etc.

279

300

280

301

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

281

302

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

375

396

a temporary directory.

376

397

377

398

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

378

content was not left behind in the stores.

399

content was not left behind in the stores.

379

400

380

401

* Web interface

381

402