~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/en/upgrade-guide/data_migration.txt

  • Committer: Ian Clatworthy
  • Date: 2009-07-02 08:26:00 UTC
  • mto: (4527.1.1 integration)
  • mto: This revision was merged to the branch mainline in revision 4529.
  • Revision ID: ian.clatworthy@canonical.com-20090702082600-qwb1evvvfa8ctnye
first draft of a 2.0 Upgrade Guide

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
Data migration
 
2
##############
 
3
 
 
4
Preparing for data migration
 
5
----------------------------
 
6
 
 
7
Before starting a migration, there are a few important things to do
 
8
first:
 
9
 
 
10
1. Take a complete backup.
 
11
 
 
12
2. Take some time to purge obsolete branches.
 
13
 
 
14
A complete backup gives you a safety net in case anything goes wrong.
 
15
 
 
16
Purging obsolete branches reduces the amount of data that needs to
 
17
be migrated. See `Finding obsolete branches`_ later for some tips
 
18
on doing this.
 
19
 
 
20
 
 
21
Introducing the upgrade-related commands
 
22
----------------------------------------
 
23
 
 
24
There are 3 important commands to be aware of when migrating data.
 
25
 
 
26
* **check** - check a repository, branch or tree for data integrity errors
 
27
 
 
28
* **reconcile** - fix data integrity errors
 
29
 
 
30
* **upgrade** - migrate data to a different format.
 
31
 
 
32
**reconcile** is rarely needed but it's good practice to run **check**
 
33
before runing **upgrade**.
 
34
 
 
35
For detailed help on these commands, see the Bazaar User Reference.
 
36
 
 
37
.. _Bazaar User Reference: ../user-reference/index.html
 
38
 
 
39
 
 
40
Migrating a standalone branch
 
41
-----------------------------
 
42
 
 
43
To do ...
 
44
 
 
45
 
 
46
Migrating branches in a shared repository
 
47
-----------------------------------------
 
48
 
 
49
To do ...
 
50
 
 
51
 
 
52
Migrating stacked branches
 
53
--------------------------
 
54
 
 
55
All branches stacked on another branch need to be upgraded **before**
 
56
the stacked on branch. For branches managed on Launchpad, the default
 
57
policy is for branches to be stacked on trunk so that means that you
 
58
need to give your community plenty of time to upgrade any branches
 
59
they own on Launchpad before you schedule the trunk upgrade.
 
60
 
 
61
To be completed ...