~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/revert.txt

  • Committer: Canonical.com Patch Queue Manager
  • Date: 2007-07-27 06:15:32 UTC
  • mfrom: (2617.5.10 win32_glob)
  • Revision ID: pqm@pqm.ubuntu.com-20070727061532-14ly852y2g2dbcb8
(Kuno Meyer) Tests for glob expansions on win32 + bugfix for `bzr
 add *` when non-ascii filenames are in working tree (#127361) (r=aaron,r=bialix)

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
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 its 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).