/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/en/user-guide/undoing_mistakes.txt

  • Committer: John Arbash Meinel
  • Date: 2009-04-16 22:06:25 UTC
  • mto: This revision was merged to the branch mainline in revision 4323.
  • Revision ID: john@arbash-meinel.com-20090416220625-hejrugy3r5qwlut9
Restore the ability to handle None as a key.
We now use _null_key instead of None to indicate the end-of-refs.
This means we now check that _null_key isn't used as an actual key.
This slows us down from 7.1 => 7.3s or so.
Interestingly, the globals lookup of _null_key was faster than
node is self._lru (7.5s+). I was a bit surprised at that.

Show diffs side-by-side

added added

removed removed

Lines of Context:
97
97
chapter, it is worth noting now that ``uncommit`` restores any pending
98
98
merges. (Running ``bzr status`` after ``uncommit`` will show these.)
99
99
``merge`` can also be used to effectively undo just a selected commit
100
 
earlier in history. For more information on ``merge``, see
101
 
`Merging changes <merging_changes.html>`_ in the next chapter and the
102
 
Bazaar User Reference.
 
100
earlier in history. For more information on ``merge``, see `Merging changes`_
 
101
in the next chapter and the Bazaar User Reference.
103
102
 
104
103
Undoing multiple commits
105
104
------------------------
133
132
This will change your entire tree back to the state as of revision 19,
134
133
which is probably only what you want if you haven't made any new commits
135
134
since then. If you have, the ``revert`` would wipe them out as well. In that
136
 
case, you probably want to use `Reverse cherrypicking
137
 
<adv_merging.html#reverse-cherrypicking>`_ instead to
 
135
case, you probably want to use `Reverse cherrypicking`_ instead to
138
136
back out the bad fix.
139
137
 
140
138
Note: As an alternative to using an absolute revision number (like 19), you can