← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/update.txt

  • Committer: Vincent Ladeuil
  • Date: 2017-01-17 13:48:10 UTC
  • mfrom: (6615.3.6 merges)
  • mto: This revision was merged to the branch mainline in revision 6620.
  • Revision ID: v.ladeuil+lp@free.fr-20170117134810-j9p3lidfy6pfyfsc
Merge 2.7, resolving conflicts

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/update.txt
1
1
"bzr update" performance analysis
2
2
=================================
3
3
 
4
 
There are 5 different slightly different situations in which bzr update 
 
4
There are 5 different slightly different situations in which bzr update
5
5
can be used:
6
6
 
7
7
* local only (no-op)
20
20
====================================
21
21
1) Need to move wt.last_rev (O(1))
22
22
2) apply delta from base to new rev (O(changes))
23
 
applying changes to files is approx (O(lines-in-files ^ 2))
 
23
   applying changes to files is approx (O(lines-in-files ^ 2))
24
24
3) update meta-info (executable bits, etc) about modified files (O(changes))
25
25
 
26
26
2/3 could be concurrent (but that may not necessarily be faster)
27
27
 
28
28
potential issue w/ serialized is having 50k files in limbo/
29
29
 
30
 
the limbo/ directory could be avoided in some cases, for example when 
 
30
the limbo/ directory could be avoided in some cases, for example when
31
31
adding new files in new directories.
32
32
 
33
33
modifying in place: reduces fragmentation of fs, not atomic
36
36
 
37
37
"local mod" is diff between disk and last commit, not merge base
38
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 
 
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
42
complexity to O(changes).
43
43
 
44
44
out of date heavyweight checkout, out of date w/master
46
46
1) open working tree, check latest revision
47
47
2) open working tree branch, check latest revision
48
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)
 
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
53
4) pull new revs M => L O(newrevs)
54
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)
 
55
   local committed changes become a pending merge
 
56
   local uncommitted stay uncommitted
 
57
   local pending merges are retained (should be gc'd)
58
58
 
59
59
offtopic:
60
60
should bzr update report where the source is ?