/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/upgrade-guide/data_migration.txt

  • Committer: Jelmer Vernooij
  • Date: 2018-07-08 14:45:27 UTC
  • mto: This revision was merged to the branch mainline in revision 7036.
  • Revision ID: jelmer@jelmer.uk-20180708144527-codhlvdcdg9y0nji
Fix a bunch of merge tests.

Show diffs side-by-side

added added

removed removed

Lines of Context:
32
32
**reconcile** is rarely needed but it's good practice to run **check**
33
33
before and after running **upgrade**.
34
34
 
35
 
For detailed help on these commands, see the `Bazaar User Reference`_.
 
35
For detailed help on these commands, see the `Breezy User Reference`_.
36
36
 
37
 
.. _Bazaar User Reference: ../user-reference/index.html
 
37
.. _Breezy User Reference: ../user-reference/index.html
38
38
 
39
39
 
40
40
Communicating with your community
50
50
   in advance.
51
51
 
52
52
This advance warning should be long enough for users to have time
53
 
to upgrade Bazaar and any required plugins before the migration date.
 
53
to upgrade Breezy and any required plugins before the migration date.
54
54
 
55
55
For larger projects, allow some time for the migration itself.
56
56
You should have a good idea of how long the migration will take
69
69
 
70
70
The steps are:
71
71
 
72
 
1. Run **bzr check**.
 
72
1. Run **brz check**.
73
73
 
74
 
2. If there are errors, try using **bzr reconcile** to fix them.
 
74
2. If there are errors, try using **brz reconcile** to fix them.
75
75
   If that fails, file a bug so we can help you resolve the issue
76
76
   and get your trunk clean. If it works, take a backup copy of
77
77
   your now clean trunk.
78
78
 
79
 
2. Run **bzr upgrade --format** where *format* is 2a or later.
 
79
2. Run **brz upgrade --format** where *format* is 2a or later.
80
80
 
81
 
3. Run **bzr check** to confirm the final result is good.
 
81
3. Run **brz check** to confirm the final result is good.
82
82
 
83
83
 
84
84
Migrating branches in a shared repository
113
113
 
114
114
In Launchpad, a project can define a *development series* and associate a
115
115
branch with that series.  The branch then becomes the *focus of development*
116
 
and gets special treatment and a shortcut url.  By default, if anybody
 
116
and gets special treatment and a shortcut URL.  By default, if anybody
117
117
branches your project's focus of development and pushes changes back to
118
118
Launchpad, their branch will be stacked on your development focus branch.
119
119
Also, branches can be associated with other Launchpad artifacts such as bugs
202
202
   name then **merge** your changes from the matching branch in the
203
203
   old repository.
204
204
 
205
 
The first method will give you a branch which is identical (in terms
206
 
of revision history) to the old branch, but it's parent branch will
207
 
be set to the old branch, not your new trunk. If you use this method,
208
 
you'll probably want to edit your branch.conf file to update the
209
 
parent branch setting.
 
205
The first method will give you a branch which is identical (in terms of
 
206
revision history) to the old branch, but it's parent branch will be set to the
 
207
old branch, not your new trunk. If you use this method, you'll probably update
 
208
the ``parent_location`` configuration variable in the ``branch.conf`` file
 
209
with::
 
210
 
 
211
    brz config parent_location=XXX
 
212
 
 
213
``XXX`` being the URL to your new trunk.
210
214
 
211
215
In contrast, the second approach sets up the parent branch correctly.
212
216
However, it isn't ideal if you're not ready to include all the latest