← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/kill-version.txt

  • Committer: Andrew Bennetts
  • Date: 2007-03-26 07:11:40 UTC
  • mto: This revision was merged to the branch mainline in revision 2376.
  • Revision ID: andrew.bennetts@canonical.com-20070326071140-s1ldac8zkl1b417h
Fix test_snapshot_new_revision to use branch.repository.get_transaction instead of branch.get_transaction.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/kill-version.txt
1
 
Killing versions
2
 
****************
3
 
 
4
 
Sometimes people really need to rewrite history.  The canonical
5
 
example is that they have accidentally checked confidential
6
 
information into the wrong tree.
7
 
 
8
 
There is a tension between two imperatives:
9
 
 
10
 
* Accurately record all history.
11
 
 
12
 
* Remove critical information.
13
 
 
14
 
Of course we cannot control who may have made use of the information
15
 
in the time it was public, but often these things are caught early enough.
16
 
 
17
 
After history has been rewritten, anything that depends on that
18
 
history may be inconsistent.  We cannot consistently continue on a
19
 
version that has had some revisions knocked out; therefore it seems
20
 
simplest to kill the version over all.  
21
 
 
22
 
You can make a tag onto a new version from a previous consistent
23
 
revision.  
24
 
 
25
 
Downstream users will need to switch on to the new version.
26
 
 
27
 
We can mark the version as killed so that mirroring will delete the
28
 
revisions and clients looking at the version can suggest switching.
29
 
 
30
 
This should be an extremely infrequent operation so it is OK that it
31
 
is simple as long as it fulfils the basic requirement.
32
 
 
33
 
A related problem is that people sometimes commit the wrong log
34
 
message, or (more seriously) the wrong files.  It is common to notice
35
 
immediately afterwards.
36
 
 
37
 
 
38
 
Uncommit
39
 
--------
40
 
 
41
 
I think this is the best and most useful option at the moment: the
42
 
`uncommit command`_ undoes the last commit, and nothing else.  It can
43
 
be repeated to successively remove more and more history.
44
 
 
45
 
.. _`uncommit command`: cmdref.html#uncommit
46
 
 
47
 
Example::
48
 
 
49
 
    % cd my-project
50
 
    % bzr add launch-codes.txt
51
 
    % bzr commit -m 'add launch codes'
52
 
    A     launch-codes.txt
53
 
    recorded r23
54
 
    [oops!]
55
 
    % bzr uncommit
56
 
    [now back to just before the commit command]
57
 
    
58
 
    % bzr status
59
 
    A     launch-codes.txt
60
 
    % bzr revert launch-codes.txt
61
 
    % bzr status
62
 
    ?     launch-codes.txt
63
 
 
64
 
If anyone else has depended on the option then the branches will have
65
 
diverged and that needs to be resolved somehow, probably by the other
66
 
people starting a new branch with the correct commit.  In particular
67
 
uncommitting from a shared branch will break anyone who has seen that
68
 
revision; possibly there needs to be a policy option on such branches
69
 
to deny uncommit.
70
 
 
71
 
If someone else on that shared branch did a the equivalent of a
72
 
switch_ command then they would bring their changes onto the correct
73
 
basis.  Would it be reasonable to do that automatically?
74
 
 
75
 
.. _switch: cmdref.html#switch
76
 
 
77
 
 
78
 
 
79
 
UI proposals
80
 
------------
81
 
 
82
 
Aaron's proposal::
83
 
 
84
 
    % cd my-project
85
 
    % baz add launch-codes.txt
86
 
    % baz commit -s 'add launch codes'
87
 
    recorded patch-4
88
 
    % baz add good-code.c
89
 
    % baz commit -s 'add good code'
90
 
    recorded patch-5
91
 
    [oops!]
92
 
    % baz undo patch-3
93
 
    % baz pull patch-5
94
 
    % baz commit --as-latest
95
 
    renamed old branch to my-project-old-1
96
 
    % baz eradicate my-project-old-1
97
 
 
98
 
Long form::
99
 
 
100
 
  % cd my-project
101
 
  % baz add launch-codes.txt
102
 
  % baz commit -s 'add launch codes'
103
 
  recorded patch-4
104
 
  % baz add good-code.c
105
 
  % baz commit -s 'add good code'
106
 
  recorded patch-5
107
 
  [oops!]
108
 
  % cd ../
109
 
  % baz fork my-project--patch3 my-project-fixed
110
 
  % cd my-project-fixed
111
 
  % baz pull ../my-project patch5
112
 
  % cd ../
113
 
  % rm -rf my-project
114
 
  % mv my-project-fixed my-project
115
 
 
116
 
Robert's proposal::
117
 
 
118
 
  % cd my-project
119
 
  % baz add launch-codes.txt
120
 
  % baz commit -s 'add launch codes'
121
 
  recorded patch-4
122
 
  % baz add good-code.c
123
 
  % baz commit -s 'add good code'
124
 
  recorded patch-5
125
 
  [oops!]
126
 
  % baz branch patch-3 $(baz tree-version)
127
 
  % baz pull . patch-5
128
 
  % baz eliminate patch-4