File: README

package info (click to toggle)
bzr-rewrite 0.6.0-1
  • links: PTS
  • area: main
  • in suites: squeeze
  • size: 252 kB
  • ctags: 256
  • sloc: python: 1,950; makefile: 45
file content (56 lines) | stat: -rw-r--r-- 2,145 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
This plugin provides a 'bzr rebase' command, in the same fashion of the 
famous git-rebase.

==========
How to use
==========
Simply run ``bzr rebase``, optionally specifying an upstream branch. If no 
branch is specified, it will use the current parent branch (which is usually 
what you want).

If the rebase fails halfway through, perhaps because of conflicts 
replaying a revision, it will abort. When it's aborted, you can either resolve
the conflicts (using "bzr resolve") and run ``bzr rebase-continue`` or 
abort the rebase and undo all changes it's done using ``bzr rebase-abort``. 
The current state of the rebase can be viewed with the ``bzr rebase-todo`` 
command. See "bzr help rebase" for more details.

In the future, I hope it can also support rebasing on top of an unrelated 
branch.

============
How it works
============
The plugin will start off by writing a plan for the rebase, which it 
will write to .bzr/checkout/rebase-state. If the rebase is interrupted 
(conflicts that have to be resolved by the user) and 
needs to be continued or aborted, it will read this file to see what needs 
(still) needs to be done.

The rebase-state file contains the following information:
 * last-revision-info when the rebase was started
 * map of revisions that need to be replaced. In simple situations, 
   this would contain the revision on top of which the rebase is taking 
   place and the revisions that are only on the branch that is being 
   rebased.

   The map is from old revid to a tuple with new revid and new parents.

   For example, in the following scenario:

   A -> B -> C -> D main
        \ -> E -> F next

   Where next would be rebased on top of main, the replace map would look 
   something like this:

	E -> (E', [D])
	F -> (F', [E'])

The rebase plan contains the newly generated revision ids so that it is 
not necessary to update it after each revision that has been written 
because the new generated revision ids would have to be known when rewriting 
their children.

The 'rebase-of' revision property of newly created revisions 
will be set to the revision id of the revision they are a rewrite of.