/brz/remove-bazaar

To get this branch, use:
bzr branch http://gegoxaren.bato24.eu/bzr/brz/remove-bazaar

« back to all changes in this revision

Viewing changes to doc/developers/revert.txt

  • Committer: Vincent Ladeuil
  • Date: 2012-01-18 14:09:19 UTC
  • mto: This revision was merged to the branch mainline in revision 6468.
  • Revision ID: v.ladeuil+lp@free.fr-20120118140919-rlvdrhpc0nq1lbwi
Change set/remove to require a lock for the branch config files.

This means that tests (or any plugin for that matter) do not requires an
explicit lock on the branch anymore to change a single option. This also
means the optimisation becomes "opt-in" and as such won't be as
spectacular as it may be and/or harder to get right (nothing fails
anymore).

This reduces the diff by ~300 lines.

Code/tests that were updating more than one config option is still taking
a lock to at least avoid some IOs and demonstrate the benefits through
the decreased number of hpss calls.

The duplication between BranchStack and BranchOnlyStack will be removed
once the same sharing is in place for local config files, at which point
the Stack class itself may be able to host the changes.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/revert.txt
 
1
Revert
 
2
======
 
3
 
 
4
Change users selected paths to be the same as those in a given revision making
 
5
backups of any paths that bzr did not set the last contents itself.
 
6
 
 
7
Least work we can hope to perform
 
8
---------------------------------
 
9
 
 
10
We should be able to do work proportional to the scope the user is reverting
 
11
and the amount of changes between the working tree and the revision being
 
12
reverted to.
 
13
 
 
14
This depends on being able to compare unchanged subtrees without recursing so that the mapping of paths to revert to ids to revert can be done efficiently. Specifically we should be able to avoid getting the transitive closure of directory contents when mapping back to paths from ids at the start of revert.
 
15
 
 
16
One way this might work is to:
 
17
for the selected scopes, for each element in the wt:
 
18
 
 
19
 1. get hash tree data for that scope.
 
20
 1. get 'new enough' hash data for the siblings of the scope: it can be out of date as long as it's not older than the last move or rename out of that siblings scope.
 
21
 1. Use the hash tree data to tune the work done in finding matching paths/ids which are different in the two trees.
 
22
 
 
23
For each thing that needs to change - group by target directory?
 
24
 
 
25
 1. Extract new content.
 
26
 1. Backup old content or replace-in-place (except windows where we move and replace).