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
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
|
Data migration
##############
Preparing for data migration
----------------------------
Before starting a migration, there are a few important things to do
first:
1. Take a complete backup.
2. Take some time to purge obsolete branches.
A complete backup gives you a safety net in case anything goes wrong.
Purging obsolete branches reduces the amount of data that needs to
be migrated. See `Finding obsolete branches`_ later for some tips
on doing this.
Introducing the upgrade-related commands
----------------------------------------
There are 3 important commands to be aware of when migrating data.
* **check** - check a repository, branch or tree for data integrity errors
* **reconcile** - fix data integrity errors
* **upgrade** - migrate data to a different format.
**reconcile** is rarely needed but it's good practice to run **check**
before and after runing **upgrade**.
For detailed help on these commands, see the `Bazaar User Reference`_.
.. _Bazaar User Reference: ../user-reference/bzr_man.html
Communicating with your community
---------------------------------
To enable a smooth transistion to the new format, you should:
1. Make one person responsible for migrating the trunk.
2. Test the migration of trunk works successfully.
3. Schedule a time for the trunk migration and notify your community
in advance.
This advance warning should be long enough for users to have time
to upgrade Bazaar and any required plugins before the migration date.
For larger projects, allow some time for the migration itself.
You should have a good idea of how long the migration will take
after doing the test migration. It may make sense to do the migration
on a weekend or a Friday, giving yourself some breathing space if
things go wrong.
After the trunk is migrated, you'll need to notify your community
accordingly, giving them instructions as to how to migrate their
local branches. Sample instructions are provided later in this
document.
Migrating a standalone branch
-----------------------------
The steps are:
1. Run **bzr check**.
2. If there are errors, try using **bzr reconcile** to fix them.
If that fails, file a bug so we can help you resolve the issue
and get your trunk clean. If it works, take a backup copy of
your now clean trunk.
2. Run **bzr upgrade --format** where *format* is 2a or later.
3. Run **bzr check** to confirm the final result is good.
Migrating branches in a shared repository
-----------------------------------------
Upgrade things in the following order:
1. Upgrade the shared repository.
2. Upgrade the branches.
3. Upgrade any lightweight checkouts.
As in the standalone branch case, be sure to run **check** before
and after the upgrade to check for any existing or introduced issues.
Migrating branches on Launchpad
-------------------------------
To allow isolation between public and private branches, Launchpad
uses stacked branches rather than shared repositories as the core
technology for efficient branch storage. The process for migrating
to a new format for projects using Launchpad code hosting is therefore
different to migrating a personal or in-house project.
Here are the steps to follow:
1. The nominated person grabs a copy of trunk and does the migration.
2. On Launchpad, unset the current trunk from being the development focus.
(This *must* be done or the following step won't work as expected.)
3. Push the migrated trunk to Launchpad.
4. Set it as the development focus.
5. Ask users subscribed to the old trunk to subscribe to the new one.
In summary, these steps mean that the old trunk is still available and
existing branches stacked on it will continue to be so. However, the
development focus has switched to the migrated trunk and any new branches
pushed to Launchpad for your project will now stack on it.
You are now ready to tell your community that the new trunk is available
and to give them instructions on migrating any local branches they have.
Migrating local branches after a central trunk has migrated
-----------------------------------------------------------
To migrate a standalone branch:
1. Grab the latest branch from the central location into a
new directory.
2. Pull or merge any changes you've made in your existing branch
into the new branch.
To migrate branches in a shared repository:
1. Create a fresh shared repository in the new format (2a or later).
2. Grab the latest branch from the central location into a
new directory inside the shared repository.
3. Decide which of your local branches you want to migrate. (If you
haven't already, now's a good time for `Finding obsolete branches`_
and purging them, after backing up first of course.)
4. To migrate each local branch of interest, there are 2 options:
* **init** an empty branch in the new repository and **pull** the
revisions from the branch in the old repository across.
* In the new repository, **branch** from trunk to the new branch
name then **merge** your changes from the matching branch in the
old repository.
The first method will give you a branch which is identical (in terms
of revision history) to the old branch, but it's parent branch will
be set to the old branch, not your new trunk. If you use this method,
you'll probably want to edit your branch.conf file to update the
parent branch setting.
In contrast, the second approach sets up the parent branch correctly.
However, it isn't ideal if you're not ready to include all the latest
revisions from trunk into that branch yet.
|