← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/update.txt

  • Committer: Robert Collins
  • Date: 2009-07-07 04:32:13 UTC
  • mto: This revision was merged to the branch mainline in revision 4524.
  • Revision ID: robertc@robertcollins.net-20090707043213-4hjjhgr40iq7gk2d
More informative assertions in xml serialisation.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/update.txt
 
1
"bzr update" performance analysis
 
2
=================================
 
3
 
 
4
There are 5 different slightly different situations in which bzr update 
 
5
can be used:
 
6
 
 
7
* local only (no-op)
 
8
* lightweight checkout
 
9
* heavy checkout
 
10
* heavy checkout w/ local changes
 
11
* bzr update could work on "bound branch" w/no wt
 
12
 
 
13
No new revisions
 
14
================
 
15
Should be O(1) to determine
 
16
Tree base is up to date
 
17
wt.last-rev == wt.b.last-rev
 
18
 
 
19
No local changes, only new revisions
 
20
====================================
 
21
1) Need to move wt.last_rev (O(1))
 
22
2) apply delta from base to new rev (O(changes))
 
23
   applying changes to files is approx (O(lines-in-files ^ 2))
 
24
3) update meta-info (executable bits, etc) about modified files (O(changes))
 
25
 
 
26
2/3 could be concurrent (but that may not necessarily be faster)
 
27
 
 
28
potential issue w/ serialized is having 50k files in limbo/
 
29
 
 
30
the limbo/ directory could be avoided in some cases, for example when 
 
31
adding new files in new directories.
 
32
 
 
33
modifying in place: reduces fragmentation of fs, not atomic
 
34
w/ local modification, potential of data loss
 
35
w/o should be safe
 
36
 
 
37
"local mod" is diff between disk and last commit, not merge base
 
38
 
 
39
Detecting name conflicts should be O(siblings). Alternatively, conflicts 
 
40
with existing files can be detected using stat() and conflicts with new files 
 
41
can be detected by examining the pending transform. This changes 
 
42
complexity to O(changes).
 
43
 
 
44
out of date heavyweight checkout, out of date w/master
 
45
=======================================================
 
46
1) open working tree, check latest revision
 
47
2) open working tree branch, check latest revision
 
48
3) mismatch => update wt => wt.b.lastrev
 
49
   apply delta to tree O(changed file size)
 
50
   ---- conflicts
 
51
   stop on conflicts
 
52
   stop always -> inform user they need to repeat (why not?, GFD)
 
53
4) pull new revs M => L O(newrevs)
 
54
5) apply delta to wt
 
55
   local committed changes become a pending merge
 
56
   local uncommitted stay uncommitted
 
57
   local pending merges are retained (should be gc'd)
 
58
 
 
59
offtopic:
 
60
should bzr update report where the source is ?
 
61
should bzr update handle both cases (local tree out-of-date w/local branch, checkout out-of-date w/master) ?
 
62
 
 
63
if updating would diverge, give opportuniuty to branch/unbind instead
 
64
local ahead, "push to master"
 
65
 
 
66
ideas:
 
67
1) can this be done as a single logical step?
 
68
2) can this be done w/o modifying working tree until end? possible performance improvements
 
69
3) if the pulling revision step could deliver full texts, that may help for the merge (same thing as "bzr pull")